In vier stappen end-to-end testen met Cypress

Begrijp me niet verkeerd: ik ben voorstander van unit tests! Maar het is net zo belangrijk om te testen hoe de Front-End en de Back-End samenwerken.

Met end-to-end testen kijk je of de Front-End goed samenwerkt met de Back-End. Zo moet bijvoorbeeld het automatisch invullen van formulieren worden getest met een end-to-end test, maar ook het klikken op knoppen en het navigeren door de pagina’s.

Deze end-to-end tests controleren dus of de Front-End de gegevens vanuit de Back-End correct verwerkt.

Wat is Cypress?

Er zijn veel end-to-end testtoolkits, maar een van de meest populaire en snelste toolkits is Cypress.

Cypress biedt een manier om end-to-end tests te schrijven met JavaScript en de testrunner. Daarnaast biedt het de mogelijkheid om screenshots en video’s op te slaan wanneer een test mislukt. En, waar de meeste organisaties blij van worden: het is open-source. En dat is geweldig.

End-to-end testen met Cypress

In de Cypress-documentatie staat een geweldige tutorial waarin je op weg wordt geholpen bij het schrijven van end-to-end-tests.

{
  "testFiles": "**/*.e2e.test.js",
  "chromeWebSecurity": false
}

In de property testFiles vertellen we Cypress om te zoeken naar bestanden die e2e.test.js in de naam bevatten. Je kunt Cypress configureren met TypeScript, maar in dit geval denk ik dat dat geen toegevoegde waarde heeft. Het vereist een extra transpilatie-stap die langer duurt.

describe('My First Test', () => {
  it('Does not do much!', () => {
    expect(true).to.equal(true)
  })
})

Dit voorbeeld lijkt op een unit-test. We moeten dus gebruik maken van de Cypress Library. Je kunt dat gebruiken door cy te gebruiken zoals in het onderstaande voorbeeld, waarin we https://example.cypress.io bezoeken.

describe('My First Test', () => {
  it('Visits the Kitchen Sink', () => {
    cy.visit('https://example.cypress.io')
  })
})

Je kunt zien dat de echte browser deze actie uitvoert door npm run e2e:open uit te voeren.

Onze scripts in de package.json zien er als volgt uit:

{
//...
"e2e:run": "npx cypress run --config-file cypress.json",
"e2e:open": "npx cypress open --config-file cypress.json",
"e2e:open:edge": "npx cypress open --browser edge --config-file cypress.json",
"e2e:open:firefox": "npx cypress open --browser firefox --config-file cypress.json"
//...
}

Cypress start de toepassing en daar kan je de end-to-end-test selecteren die je wilt uitvoeren. Standaard wordt de Chrome-browser geopend, maar er is ook een optie om het in Firefox of Edge uit te voeren.

Cypress biedt een complete bibliotheek en je kunt de documentatie raadplegen voor meer informatie hierover.

describe('My First Test', () => {
  it('Visits the Kitchen Sink', () => {
    cy.visit('https://example.cypress.io');
    cy.get('h1').should('contain.text', ' Dit is een geweldige titel');
  })
})

In dit voorbeeld maakt elke methode die je aanroept vanuit de cy-bibliotheek deel uit van het testen. Zo zal cy.visit() de actie uitvoeren, maar als er geen geldige pagina op die URL staat, zal de test niet slagen. Dus met elke actie die je uitvoert, begin je een ‘assertion’.

In Cypress zijn er twee verschillende soorten ‘assertions’. should() of and() zijn “Implicit Subjects”. .expect is een “Explicit Subject”. Lees hier meer over in de Cypress-documentatie.

Bij het aanroepen van cy.get(‘h1’) zal het zoeken naar de H1-tag. Wanneer het dat element vindt, gaat de test verder. De test zal falen indien het element niet binnen een paar milliseconden wordt gevonden. Na de get-method kun je een heleboel andere methoden koppelen, zoals:

• .contains() verwacht dat het element met inhoud uiteindelijk in de DOM zal bestaan.
• .find() verwacht ook dat het element uiteindelijk in de DOM zal bestaan.
• .type() verwacht dat het element uiteindelijk in een typbare staat zal zijn.
• .click() verwacht dat het element zich uiteindelijk in een bruikbare staat bevindt.
• .its() verwacht uiteindelijk een property over het huidige onderwerp te vinden.

Dus wat testen we met end-to-end-tests?

1. Of een element een bepaalde klasse heeft (cy.get(‘element.selector’).should(‘have.class’, ‘ng-valid’); ) of juist niet (cy.get(‘element.selector’).should(‘not.have.class’, ‘ng-valid’);).
2. Of een lijst 3 onderliggende elementen heeft ( cy.get(‘ul > li’).should(‘have.length’, 3); ).
3. Controleren of een invoerveld of tekstgebied een bepaalde waarde heeft ( cy.get(‘input[name=“firstName”]’).type(‘Santa Claus’).should(‘have.value’, ‘Santa Claus’); ).

Bekijk deze lijst met voorbeelden van wat je kunt gebruiken in de should-method.

Extra voorbeeld:

Je kunt de context van een bovenliggend element toevoegen om assertions uit te voeren, wat handig is bij formulieren.

<form>
  <input name="email" type="email" />
  <input name="password" type="password" />
  <button type="submit">Login</button>
</form>

describe('My First Test', () => {
  it('Visits the Kitchen Sink', () => {
    cy.visit('https://example.cypress.io');
    cy.get('form').within(($form) => {
        // you have access to the found form via
        // the jQuery object $form if you need it

        // cy.get() will only search for elements within form,
        // not within the entire document
        cy.get('input[name="email"]').type('john.doe@email.com')
        cy.get('input[name="password"]').type('password')
        cy.root().submit()
    })
  })
})

Kijk voor meer voorbeelden van de within()-method in de Cypress-documentatie.

Herbruikbare functionaliteit

In het geval van herbruikbare acties die je keer op keer uitvoert, kan je eenvoudige functies schrijven die je in een lib-map kunt plaatsen. Maar Cypress biedt een gebruiksvriendelijkere manier om dit te doen. Dit wordt “custom commands” genoemd; hiervan kan je veel voorbeelden vinden in de documentatie.

Maar een van de beste voorbeelden is het schrijven van de command voor de login. Je moet die code toevoegen aan het bestand cypress/support/commands.js.

Cypress.Commands.add('login', (userType, options = {}) => {
  // this is an example of skipping your UI and logging in programmatically

  // setup some basic types
  // and user properties
  const types = {
    admin: {
      name: 'Jane Lane',
      admin: true,
    },
    user: {
      name: 'Jim Bob',
      admin: false,
    },
  }

  // grab the user
  const user = types[userType]

  // create the user first in the DB
  cy.request({
    url: '/seed/users', // assuming you've exposed a seeds route
    method: 'POST',
    body: user,
  })
    .its('body')
    .then((body) => {
      // assuming the server sends back the user details
      // including a randomly generated password
      //
      // we can now login as this newly created user
      cy.request({
        url: '/login',
        method: 'POST',
        body: {
          email: body.email,
          password: body.password,
        },
      })
    })
})

Conclusie

Nu is het aan jou om geweldige end-to-end tests te schrijven met Cypress! Perfecte tests bestaan niet, maar als je ze elke keer een beetje optimaliseert, wordt het je ‘source of truth’. De end-to-end-tests zijn geweldig voor developers om uit te voeren na het bouwen van een nieuwe functie of het wijzigen van een bestaande, omdat het onmogelijk is om alle testscenario’s te onthouden.

Veel succes en plezier met het schrijven van waardevolle end-to-end tests! Als we je hierbij kunnen helpen, doen mijn collega’s en ik dat natuurlijk graag.