How to use stripLeadingCyDirs method in Cypress

After much nashing-of-teeth, I think I have an answer.

I think the root cause is that mdc-select-item has display:flex, which allows it to exceed the bounds of it's parents (strictly speaking, this feels like the wrong application of display flex, if I remember the tutorial correctly, however...).

Cypress does a lot of parent checking when determining visibilty, see visibility.coffee,

## WARNING:
## developer beware. visibility is a sink hole
## that leads to sheer madness. you should
## avoid this file before its too late.
...
when $parent = parentHasDisplayNone($el.parent())
  parentNode = $elements.stringify($parent, "short")

  "This element '#{node}' is not visible because its parent '#{parentNode}' has CSS property: 'display: none'"
...
when $parent = parentHasNoOffsetWidthOrHeightAndOverflowHidden($el.parent())
  parentNode  = $elements.stringify($parent, "short")
  width       = elOffsetWidth($parent)
  height      = elOffsetHeight($parent)

  "This element '#{node}' is not visible because its parent '#{parentNode}' has CSS property: 'overflow: hidden' and an effective width and height of: '#{width} x #{height}' pixels."

But, when using .should('be.visible'), we are stuck with parent properties failing child visibility check, even though we can actually see the child.
We need an alternate test.

The work-around

Ref jquery.js, this is one definition for visibility of the element itself (ignoring parent properties).

jQuery.expr.pseudos.visible = function( elem ) {
  return !!( elem.offsetWidth || elem.offsetHeight || elem.getClientRects().length );
}

so we might use that as the basis for an alternative.

describe('Testing select options', function() {

  // Change this function if other criteria are required.
  const isVisible = (elem) => !!( 
    elem.offsetWidth || 
    elem.offsetHeight || 
    elem.getClientRects().length 
  )

  it('checks select option is visible', function() {

    const doc = cy.visit('http://localhost:4200')
    cy.get("mdc-select").contains("installation type").click()

    //cy.get('mdc-select-item').contains("ITEM1").should('be.visible') //this will fail
    cy.get('mdc-select-item').contains("ITEM1").then (item1 => {
      expect(isVisible(item1[0])).to.be.true
    });
  });

  it('checks select option is not visible', function() {

    const doc = cy.visit('http://localhost:4200')
    cy.get("mdc-select").contains("installation type").click()

    cy.document().then(function(document) {

      const item1 = document.querySelectorAll('mdc-select-item')[0]
      item1.style.display = 'none'

      cy.get('mdc-select-item').contains("ITEM1").then (item => {
        expect(isVisible(item[0])).to.be.false
      })
    })
  });

  it('checks select option is clickable', function() {

    const doc = cy.visit('http://localhost:4200')
    cy.get("mdc-select").contains("installation type").click()
    
    //cy.get('mdc-select-item').contains("ITEM1").click()    // this will fail
    cy.get('mdc-select-item').contains("ITEM1").then (item1 => {
    
      cy.get('mdc-select-item').contains("ITEM2").then (item2 => {
        expect(isVisible(item2[0])).to.be.true  //visible when list is first dropped
      });
          
      item1.click();
      cy.wait(500)
          
      cy.get('mdc-select-item').contains("ITEM2").then (item2 => {
        expect(isVisible(item2[0])).to.be.false  // not visible after item1 selected
      });
    });
    
  })

Footnote - Use of 'then' (or 'each')

The way you normally use assertion in cypress is via command chains, which basically wraps the elements being tested and handles things like retry and waiting for DOM changes.

However, in this case we have a contradiction between the standard visibility assertion .should('be.visible') and the framework used to build the page, so we use then(fn) (ref) to get access to the unwrapped DOM. We can then apply our own version of the visibility test using stand jasmine expect syntax.

It turns out you can also use a function with .should(fn), this works as well

it('checks select option is visible - 2', function() {
  const doc = cy.visit('http://localhost:4200')
  cy.get("mdc-select").contains("installation type").click()

  cy.get('mdc-select-item').contains("ITEM1").should(item1 => {
    expect(isVisible(item1[0])).to.be.true
  });
});

Using should instead of then makes no difference in the visibility test, but note the should version can retry the function multiple times, so it can't be used with click test (for example).

From the docs,

What’s the difference between .then() and .should()/.and()?

Using .then() simply allows you to use the yielded subject in a callback function and should be used when you need to manipulate some values or do some actions.

When using a callback function with .should() or .and(), on the other hand, there is special logic to rerun the callback function until no assertions throw within it. You should be careful of side affects in a .should() or .and() callback function that you would not want performed multiple times.

You can also solve the problem by extending chai assertions, but the documentation for this isn't extensive, so potentially it's more work.

You might want to use the Cypress Module API to invoke cypress run and control the exit code.

This is my script which differs from the docs example slightly,

/scripts/cy-run.js

const cypress = require('cypress')

const args = process.argv.slice(2);
const options = ['cypress', 'run', ...args]; // saves passing 'cypress run' on the command line

cypress.cli.parseRunArguments(options).then(runOptions => {

  console.log('runOptions', runOptions)

  cypress.run(runOptions).then(() => {

    process.exit(0);   // control the exit code 

  }).catch(error => {
    console.error(error);
  })
}).catch(error => {
  console.error(error)
})

package.json

{
  ...
  "scripts": {
    "cyrun": "node scripts/cy-run.js",
    "postcyrun": "echo next command",

sample test

it('succeeds', () => {
  expect(1+1).to.equal(2)
})

it('fails', () => {
  expect(1+1).to.equal(3)
})

command line

yarn cyrun --spec "**/test.spec.js" --browser chrome

console output

node scripts/cy-run.js --spec **/test.spec.js --browser chrome
runOptions { browser: 'chrome', spec: '**/test.spec.js' }


==================================================================================================

  (Run Starting)

  ┌──────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Cypress:    5.5.0                                                                            │
  │ Browser:    Chrome 86                                                                        │
  │ Specs:      1 found (test.spec.js)                                                           │
  │ Searched:   **\test.spec.js                                                                  │
  └──────────────────────────────────────────────────────────────────────────────────────────────┘

... test details

==================================================================================================

  (Run Finished)


       Spec                                              Tests  Passing  Failing  Pending  Skipped
  ┌──────────────────────────────────────────────────────────────────────────────────────────────┐
  │ ×  test.spec.js                           820ms        2        1        1        -        - │
  └──────────────────────────────────────────────────────────────────────────────────────────────┘
    ×  1 of 1 failed (100%)                   820ms        2        1        1        -        -

$ echo next command
next command          // postcyrun is running
Done in 14.35s.

Code below will help you to stub window.open and further assert it that function has been triggered:

it('opens the about page', () => {
  cy.visit('/')
  cy.window().then(win => {
    cy.stub(win, 'open').as('Open')
  })
  cy.get('.your-selector').click()
  cy.get('@Open').should('have.been.calledOnceWithExactly', yourUrl)
})

You also can stub window.open in cy.on hook as you did, what helps you to yield new window object each time after page reload. However, if you want to actually open the new Url in existing tab instead of new one you can use this code below by passing "_self" param to overwrite old "_blank":

cy.window().then(win => {
          cy.stub(win, 'open').callsFake((url) => {
            return win.open.wrappedMethod.call(win, url, '_self');
          }).as('Open');
        });

callsFake function dynamically withdraws url which has been placed into original window.open(url, "_blank"), or you can manually change url inside .call(win, url, '_self'); with static one, so regardless on which link or button you clicked, which triggers window.open, they all will open the same url.

Cypress has the clearCookie command, but it can't be used inside the intercept callback.

cy.intercept(logoutRoute, request => {
  cy.clearCookie('magic-auth-token')
  request.reply...
})

This is the error

CypressError

Cypress detected that you returned a promise from a command while also invoking one or more cy commands in that promise.

The cy command you invoked inside the promise was: cy.clearCookie()

Looking at the source code for clearCookie, it boils down to the internal command

Cypress.automation('clear:cookie', { name: <cookie-name> })

While it's an internal command, it's use has been demo'd here Cypress Automation and here Testing an Application in Offline Network Mode

The type definitions were added recently Add type for Cypress.automation #7573

Here's a proof of concept,

it('clears cookies in intercept', () => {

  cy.setCookie('magic-auth-token', '1234')
  cy.getCookies().should('have.length', 1)

  cy.intercept('*', (req) => {
    Cypress.automation('clear:cookie', { name: 'magic-auth-token' })
  })

  cy.visit('http://example.com').then(() => {
    // after the request has been intercepted
    cy.getCookies().should('have.length', 0)
  })
})

I was able to solve this by

//cypress/support/index.js

Cypress.Server.defaults({
  ignore: xhr => {
    return Cypress.config().blockHosts.some(blockedHost =>  // get blockHosts from cypress.json using Cypress.config()
      Cypress.minimatch(new URL(xhr.url).host, blockedHost)  // if current url matches any blockedHost item, return true
    )
  }
})

more details on https://github.com/cypress-io/cypress/discussions/16536

Try something like this:

Cypress.on('test:after:run', (test, runnable) => {
if (test.state === 'failed') {
    const screenshotFileName = `${Cypress.config('screenshotsFolder')}/${Cypress.spec.name}/${runnable.parent.title} -- ${test.title} (failed).png`
    addContext({ test }, screenshotFileName)
}

})

There are two major differences.

First, the two functions handle filepaths differently.

cy.readFile() starts at your cypress project folder, the folder where your cypress.json is. In other words, cy.readFile("test.txt") will read from (path-to-project)\test.txt.

cy.fixture() starts in the fixtures folder. cy.fixture("test.txt") will read from (path-to-project)\cypress\fixtures\test.txt. Note that this may be different if you have set a fixtures path in your cypress.json.

Absolute file paths do not appear to be supported here.

Second, cy.fixture() tries to guess the file's encoding.

cy.fixture() assumes the encoding for certain file extensions while cy.readFile() does not, except in at least one special case (see below).

For example, cy.readFile('somefile.png') will interpret it as a text document and just blindly read it into a string. This produces garbage output when printed to console. However, cy.fixture('somefile.png') will instead read in the PNG file and convert it to a base64-encoded string.

This difference isn't in the ability of the two functions, but instead appears to be in default behavior; if you specify the encoding, both functions act identically:

cy.readFile('path/to/test.png', 'base64').then(text => {
    console.log(text); // Outputs a base64 string to the console
});

cy.fixture('path/to/test.png', 'base64').then(text => {
    console.log(text); // Outputs the same base64 string to the console
});

Note:

cy.readFile() doesn't always read in plain text. cy.readFile() gives back a Javascript object when reading JSON files:

cy.readFile('test.json').then(obj => {
    // prints an object to console
    console.log(obj);
});

It would be best to use a Scenario Outline.
Using this, your entire scenario will be executed 2 times (or the # of rows you add in your table under Examples) and each time, the words with angle brackets <value> and <message> will be replaced by their corresponding value from the Examples: table.

Scenario Outline: The one where the user enters value <value> to calculate the factorial
     Given  the user navigates to the Factoriall calculator screen
     When   the user enters value <value> into the input box
     And    the user clicks the Calculate button
     Then   this message is displayed to the user: <message>
     Examples:
         | value | message                           |
         | 12    | The factorial of 12 is: 479001600 |
         | 34.56 | Please enter an integer           |

To use the values <value> and <message>, your need to call your step like this:

When(/^the user enters value (.+) into the input box$/, (value) => {
    ...
});

Then(/^this message is displayed to the user: (.+)$/, (message) => {
    ...
});

In my example above, I use regular expressions to capture my variables. There are other ways, but I prefer this one.

you can use contain keyword to look string that contain a substring

with should to perform directly the assertion

cy.get('[data-id="error"]').should('contain', 'is missing')

or get only element that contain text with contains

cy.get('[data-id="error"]').contains('is missing')

them perform needed assertion on it