How to use win.webContents.debugger.sendCommand method in Cypress

Accessing new windows via Cypress is intentionally not supported.

However, there are many ways this functionality can be tested in Cypress now. You can split up your tests into separate pieces and still have confidence that your application is covered.

1. Write a test to check that when performing the action in your app, the window.open event is called by using cy.spy() to listen for a window.open event.

cy.visit('http://localhost:3000', {
  onBeforeLoad(win) {
    cy.stub(win, 'open')
  }
})

// Do the action in your app like cy.get('.open-window-btn').click()

cy.window().its('open').should('be.called')

2. In a new test, use cy.visit() to go to the url that would have opened in the new window, fill in the fields and click the buttons like you would in a Cypress test.

cy.visit('http://localhost:3000/new-window')

// Do the actions you want to test in the new window

Fully working test example can be found here.

You generally want to set up the data so that each scenario is present in the table for different tests (one test per scenario). Then it's just a simple matter of asserting the disabled class, for example

Scenario 1

cy.contains('cbutton1').should('not.have.class', 'disabled')    
cy.contains('xbutton1').should('have.class', 'disabled')
...  // etc

I'm assuming that the presence of the disabled class is the key thing to test, seems logical.

You can also do this in a data-driven way if there's a lot of scenarios to handle.

I'm not sure the cy.contains('xbutton1') gets you where you need to go.

In your DOM, the first disabled element has <p>iris description!</p>. If this is the element that would show up in the table cell, then

cy.contains('iris description!').should('have.class', 'disabled')

would not work. You may have to navigate to the parent, like this

cy.contains('p', 'iris description!')   // more specific, grabs the <p>
  .parents('[class="hardwareCardRow"]') // get the parent row
  .find('[data-cy-id="cbutton1"]')      // go cell that should be disabled
  .should('have.class', 'disabled')     // assert it is disabled

Data-driven tests might look something like this

const scenarios = [
  { option: 'Option1', cellText: 'iris description!', disabledItem: 'cbutton1' },
  { option: 'Option2', cellText: 'lily description!', disabledItem: 'cbutton2' },
  // etc
}

scenarios.forEach(data => {
  
  it(`should be disabled, testing ${data.option}`, () => {  // back-ticks on description
                                                            // for template literal
    cy.contains('p', data.cellText)
      .parents('[class="hardwareCardRow"]') 
      .find(`[data-cy-id="${data.disabledItem}"]`) // back-ticks on the selector
      .should('have.class', 'disabled')    

  })
})

Start with a fix to cypress.json

{
  "env": {
    "links": {
      "staging": "https://staginglink",
      "live": "https://livelink"
    }
    "users": {
      "user1": {"username": "username1", "password" : "password1"},
      "user2": {"username": "username2", "password" : "password2"},
    }
}

Calling with string parameters:

cy.login('live', 'user2')  

Command:

Cypress.Commands.add("login", (requiredEnv, requiredUser) => {

  const links = Cypress.env('links');  // links section above
  const link = links[requiredEnv];     // if passed "live" or "staging", gives the
                                       // correct property of links section
  cy.visit(link)

  const users = Cypress.env('users');    // users section above
  const user = users[requiredUser];          

  const username = user.username;  // "user1" -> gives "username1"
                                   // "user2" -> gives "username2"

  const password = user.password;  // "user1" -> gives "password1"
                                   // "user2" -> gives "password2"

  cy.get('input[name="Parameter.UserName"]').type(username)  // don't put quotes around variable
  cy.get('input[name="Parameter.Password"]').type(password)  // don't put quotes around variable
  cy.contains('Login').click()
})

To check if the status of the response is not 200, add the failOnStatusCode: false option.

Cypress catches internal errors and does not re-throw them so expect(...).to.throw is not going to see anything.

cy.request({
  method: 'POST',
  // url: `https://valid.url/api/items`,
  url: 'http://example.com/api/items',
  body: {name: "foo"},
  failOnStatusCode: false
})
.then(response => {
  expect(response.status).to.be.gt(299)  // status returned is 404
})

The 500: Internal Server Error is specific to your API, but cy.request is doing it's job as by default it is configured to fail the test when the request fails.

Cypress has an event called url:changed. See doc on Events here

Using this, something like this may work:

context("Workflow", () => {
    it("login", () => {

        cy.on('url:changed', url => {
            cy.location('hash').then(hash => {
                if (!url.endsWith(hash)) {
                    cy.visit(url);
                }
            });
        });

        cy.visit("http://localhost:3000/src/#login")
        cy.get("#username").type("demo").should("have.value", "demouser")
        cy.get("#password").type("demo{enter}").should("have.value", "demo") // this should redirect to "/#home"
        cy.get(".subtitle").should("have.value", "Welcome") //this line fails as ".subtitle" is an element of "/#home"

    })
})

Edit: just for troubleshooting purposes and to focus on your issue, can you try it like this without cy.location():

context("Workflow", () => {
    it("login", () => {

        cy.on('url:changed', url => {
            cy.visit(url);
        });

        cy.visit("http://localhost:3000/src/#login")
        cy.get("#username").type("demo").should("have.value", "demouser")
        cy.get("#password").type("demo{enter}").should("have.value", "demo") // this should redirect to "/#home"
        cy.get(".subtitle").should("have.value", "Welcome") //this line fails as ".subtitle" is an element of "/#home"

    })
})

Edit: Have you tried cy.reload()

context("Workflow", () => {

    it("login", () => {

        cy.visit("http://localhost:3000/src/#login")
        cy.get("#username").type("demo").should("have.value", "demouser")
        cy.get("#password").type("demo{enter}").should("have.value", "demo") // this should redirect to "/#home"
        cy.reload();
        cy.get(".subtitle").should("have.value", "Welcome");
    })
})

With this recursive function you just need to pass a variable that decrements (or maybe increments to a max)

function deleteAllFoundProducts(rowCount) {
  if (rowCount < 1) return // if no rows remain, terminate recursion
  cy.get('span[title="Delete"]', {timeout: 10000}).first().click()
  cy.get('.tBtn[title="Yes"]').click().then(() => {
    cy.get('.loader', {timeout: 10000}).should('not.exist') // wait for list to reappear
    deleteAllFoundProducts(--rowCount) // try again
  })
}

cy.get('tbody tr')
  .then(rows => deleteAllFoundProducts(rows.length))  // first call here

This will still work when there's a "No matching records found" row appended after deleting all rows, since rowCount is obtained before deletions start.

Regardless of whether or not your custom command returns a cypress chain, you can run code after the command wrapping it in a then callback:

describe('Summary Page', () => {
  it('my demo test', () => {
    console.log('before command runs')
    cy.testCommand()
    cy.then(() => {
      console.log('after command runs')
    })
  })
})

As for using async/await, Cypress by default does not support async/await, see this issue and the long discussion inside it.

To reduce the number of callback you may try either cypress-promise or cypress-thenify libraries. However, each of them has it's own limitations.

You could follow the new documentation here and You could setup it as follows :

Create new vue project :

************************* VUE CLI ****************************

vue create project-name

Then change directory to the new created project to add vuetify

cd project-name

then

vue add vuetify

Choose the vuetify 3 preset Vuetify 3 - Vue CLI (preview 3) :

? Choose a preset:
  Vuetify 2 - Configure Vue CLI (advanced)
  Vuetify 2 - Vue CLI (recommended)
  Vuetify 2 - Prototype (rapid development)
  Vuetify 3 - Vite (preview)
❯ Vuetify 3 - Vue CLI (preview 3)

this changes the main.js file to :

import { createApp } from 'vue'
import vuetify from './plugins/vuetify'
import App from './App.vue'

const app = createApp(App)
app.use(vuetify)

app.mount('#app')

./plugins/vuetify

import '@mdi/font/css/materialdesignicons.css'
import 'vuetify/lib/styles/main.sass'
import { createVuetify } from 'vuetify'
import * as components from 'vuetify/lib/components'
import * as directives from 'vuetify/lib/directives'

export default createVuetify({
  components,
  directives,
})

************************* VITE ****************************

Create Vue 3 project following these commands :

npm init vue@latest

Then answer the different prompts :

✔ Project name: … <your-project-name>
✔ Add TypeScript? … No / Yes
✔ Add JSX Support? … No / Yes
✔ Add Vue Router for Single Page Application development? … No / Yes
✔ Add Pinia for state management? … No / Yes
✔ Add Vitest for Unit testing? … No / Yes
✔ Add Cypress for both Unit and End-to-End testing? … No / Yes
✔ Add ESLint for code quality? … No / Yes
✔ Add Prettier for code formatting? … No / Yes

Scaffolding project in ./<your-project-name>...
Done.

finally install vuetify 3 and @mdi/font:

npm i vuetify@next @mdi/font

and change the main.js as above.

You could fork this repository to get started

I got some feedback that the above "ERROR:system_services.cc(34)" is not critical and does not cause flaky or unsuccessful tests, therefore there are no action points.