How to use getSuperDomain method in Cypress

At Pactflow, we've spent about 6 months using Cypress and Pact together, using the Pact mock service to generate pacts from our Cypress tests as suggested in https://pactflow.io/blog/cypress-pact-front-end-testing-with-confidence/

We have this week decided to change our approach, for the following reasons.

1. Our Cypress tests are much slower than our unit tests (15+ minutes), so generating the pact, and then getting it verified takes a lot longer when we generate the pact from our Cypress tests vs our unit tests.
2. Our Cypress tests can fail for reasons that are not to do with Pact (eg. layout changes, issues with the memory consumption on the build nodes, UI library upgrades etc) and this stops the pact from being generated.
3. The Cypress intercept() and mock service don't play very nicely together. Any request that does not have an explicit intercept() for Cypress ends up at the mock service, and every time a new endpoint is used by the page, the request hits the mock service, which then fails the overall test, even if that endpoint was not required for that specific test.
4. When a Cypress test fails, there is very good debugging provided by the Cypress library. When it fails for reasons to do with Pact, it's currently hard to identify the cause, because that information is not displayed in the browser (this could potentially be improved, however, it won't mitigate the already listed issues).

Our new approach is to generate our Pacts from our unit tests (instead of our Cypress tests) and to share the fixtures between the unit and Cypress tests, using a function that strips of the Pact matchers. eg.

const SOME_INTERACTION = {
  state: 'some state',
  uponReceiving: "some request",
  withRequest: {
    method: "GET",
    path: "/something"
  },
  willRespondWith: {
    status: 200,
    body: {
      something: like("hello")
    }
  }
}

Unit test

describe('Something', () => {
  let someProviderMockService
  beforeAll(() => {
    someProviderMockService = new Pact({
      consumer: 'some-consumer',
      provider: 'some-provider'
    })
    return someProviderMockService.setup()
  })
  afterAll(() => someProviderMockService.finalize())
  afterEach(() => someProviderMockService.verify())

  describe('loadSomething', () => {
    beforeEach(() => {
      return someProviderMockService.addInteraction(SOME_INTERACTION)
    })

    it('returns something', async () => {
      const something = await loadSomething()
      //expectations here
    })
  })
})

Function that turns the Pact interaction format into Cypress route format, and strips out the Pact matchers.

const Matchers = require('@pact-foundation/pact-web').Matchers

// TODO map the request body and query parameters too
const toCypressInteraction = (interaction) => {
  return {
    method: interaction.withRequest.method,
    url: Matchers.extractPayload(interaction.withRequest.path),
    status: interaction.willRespondWith.status,
    headers: Matchers.extractPayload(interaction.willRespondWith.headers),
    response: Matchers.extractPayload(interaction.willRespondWith.body)
  }
}

In the Cypress test

cy.route(toCypressInteraction(SOME_INTERACTION))

This approach has the following benefits:

1. The pact is generated quickly.
2. The pact is generated reliably.
3. The Cypress tests are more reliable and easier to debug.
4. The requests used in the Cypress tests are verified to be correct.
5. There is less chance of "interaction bloat", where interactions are added merely to test UI features, rather than because they provide valuable coverage.

I hope this information is helpful for you. We now recommend this approach over direct use of the mock service in Cypress tests.

Updated for Cypress v7.0.0 Released 04/05/2021

The change-log shows from this release the intercepts are now called in reverse order

Response handlers (supplied via event handlers or via req.continue(cb)) supplied to cy.intercept() will be called in reverse order until res.send is called or until there are no more response handlers.

Also illustrated in this diagram from the documentation

When you set up identical intercepts, the first one will grab all the calls. But you can wait on the first alias multiple times.

Here's a (reasonably) simple illustration

spec

Cypress.config('defaultCommandTimeout', 10); // low timeout
                                             // makes the gets depend on the waits 
                                             // for success

it('never fires @call2',()=>{

  cy.intercept({ pathname: "/posts", method: "POST" }).as("call1")
  cy.intercept({ pathname: "/posts", method: "POST" }).as("call2")

  cy.visit('../app/intercept-identical.html')
  
  cy.wait('@call1')                               // call1 fires 
  cy.get('div#1').should('have.text', '201')

  cy.wait('@call2')                               // call2 never fires
  cy.wait('@call1')                               // call1 fires a second time
  cy.get('div#2').should('have.text', '201')

})

app

<body>
  <div id="1"></div>
  <div id="2"></div>
  <script>

    setTimeout(() => {
      fetch('https://jsonplaceholder.typicode.com/posts', {
        method: 'POST',
        body: JSON.stringify({ title: 'foo', body: 'bar', userId: 1 }),
        headers: { 'Content-type': 'application/json; charset=UTF-8' },
      }).then(response => {
        document.getElementById('1').innerText = response.status;
      })
    }, 500)
  
    setTimeout(() => {
      fetch('https://jsonplaceholder.typicode.com/posts', {
        method: 'POST',
        body: JSON.stringify({ title: 'foo', body: 'bar', userId: 2 }),
        headers: { 'Content-type': 'application/json; charset=UTF-8' },
      }).then(response => {
        document.getElementById('2').innerText = response.status;
      })
    }, 1000)

  </script>
</body>

You can see it in the Cypress log,

So something that really kinda sucks right now is react released v17 late last year, and it was pretty much 100% backwards compatible with 16. This means anybody on 16 could upgrade to 17 without any issues. However, there are still many packages out there that list react 16 as a peer dependency but not 17. Well npm v7 changed the way they handle peer dependencies in such a way that you are getting this error. Your best bet is to

1. Create an issue and submit a PR to the offending package react-inspector
2. In the mean time, use --force or --legacy-peer-deps as the error instructs.

EDIT: However, checking the react-inspector project, it looks as though they are listing v17 in their peer deps. Try deleting your package-lock.json and deleting your node_modules and do a fresh install.

should('have.text', text) should work

cy.get('td').eq(1).should('have.text', 'hello')

If there's whitespace around text, use contain.text

cy.get('td').eq(1).should('contain.text', 'hello')

Please see chaijs .a(type[, msg])

Asserts that the target’s type is equal to the given string type. Types are case insensitive.

expect(undefined).to.be.an('undefined')

The .a() or .an() is doing a typeof check that returns a string, so you just need to quote the "undefined" type

cy.wrap(user).should('not.be.a', "undefined")

or drop the .a to do a reference check instead

cy.wrap(user).should('not.be', undefined)

You can do something like this. This will iterate through all the .course classes and inside that click on the button with text as Register one by one.

cy.get('.course').each(($ele) => {
    cy.wrap($ele).find('button').contains('Register').click()
})

OR

cy.get('.course').each(($ele) => {
    cy.wrap($ele).find('button').eq(1).click()
})

Cypress has documentation and examples for all major CI providers, including Jenkins: https://docs.cypress.io/guides/guides/continuous-integration.html

Here is an example Jenkinsfile for the Cypress example project: https://github.com/cypress-io/cypress-example-kitchensink/blob/master/Jenkinsfile

Vue translates

<v-btn class="submit-button">Log In</v-btn>

into

<button class="submit-button">
  <span class="v-btn__content">Log In</span>
</button>

Logically this test

cy.get('.submit-button').type('{enter}');

should work since you are selecting the button element by it's class, but somehow the focus is getting messed up.

The fix is to insert a .focus() before the .type() command.

cy.get('.submit-button').focus().type('{enter}');

Preserve cookies between tests with Cypress.preserveOnce(), or in beforeEach() preserves for all tests.

beforeEach(() => {
  Cypress.Cookies.preserveOnce('test_email')
})

it('set cookie', async () => {
  cy.setCookie('test_email', 'fake@email.com')
})

it('once', async () => {
  const email = await cy.getCookie('test_email')
  expect(email).to.have.property('value', 'fake@email.com')  // passes
})

it('twice', async () => {
  const email = await cy.getCookie('test_email')
  expect(email).to.have.property('value', 'fake@email.com')  // passes
})

it('thrice', async () => {
  const email = await cy.getCookie('test_email')
  expect(email).to.have.property('value', 'fake@email.com')  // passes
})

You should stick with the documented way of using getCookie.

If I run

const email = await cy.getCookie(...)

after a cy.visit(), I get undefined.

If I use

cy.getCookie(...).then(...) 

on the next line it gets the value.

Since Cypress has not documented the await syntax anywhere, you are likely to get some flaky results.

Standard pattern is:

it('once', () => {
  cy.getCookie('test_email').then(email => {
    expect(email).to.have.property('value', 'fake@email.com')  // passes
  })
})

If you run tests in CI they may be run parallel, so better to setCookie in before() or beforeEach().

before(() => {
  cy.setCookie('test_email', 'fake@email.com')
})

beforeEach(() => {
  Cypress.Cookies.preserveOnce('test_email')
})

it('uses cookie once', () => {
  ...
})

it('uses cookie twice', () => {
  ...
})

it('uses cookie thrice', () => {
  ...
})