Rodzaje asercji w Cypress: praktyczny przewodnik z przykładami

1. Co to jest asercja?

Krótka definicja:

Asercja to warunek, który musi zostać spełniony, aby test uznać za poprawny. Jeśli nie zostanie spełniony – test się wywala.

Przykład:

cy.get('.button').should('be.visible')

2. Podział asercji w Cypress

✅ Asercje podstawowe (domyślne matchery)

• should('exist')

• should('be.visible')

• should('contain', 'Tekst')

• should('have.class', 'active')

Kiedy używać:
Do sprawdzania obecności, widoczności, zawartości tekstu – najczęstsze przypadki UI.

🧪 Asercje logiczne i zagnieżdżone

• should('not.exist')

• .and('have.attr', 'href', '/home')

• should('include.text', 'Witaj')

Tip: Możesz łączyć kilka asercji:

cy.get('button')
  .should('be.visible')
  .and('have.text', 'Zaloguj się')

🧠 Asercje z funkcją callback

cy.get('ul li').should(($items) => {
  expect($items.length).to.eq(5)
})

Kiedy używać:
Gdy potrzebujesz bardziej złożonej logiki – np. sprawdzić długość, warunki niestandardowe, zawartość kolekcji.

🌐 Asercje po zapytaniach API (Cypress + cy.request())

cy.request('/api/users').then((response) => {
  expect(response.status).to.eq(200)
  expect(response.body).to.have.length.greaterThan(0)
})

Kiedy używać:
Podczas testów backendu lub API bez interfejsu graficznego.

🧷 Asercje na danych (z cy.fixture() lub cy.readFile())

 cy.fixture('user.json').then((user) => {
expect(user.name).to.equal('Rafał')
})

Kiedy:
Gdy testujesz uploady, downloady lub konkretne dane wejściowe.

🚫 Błędy, które często się pojawiają

• Użycie should('not.exist') na elementach, które są ładowane z opóźnieniem (zbyt szybkie sprawdzanie)

• should('have.text', 'coś') zamiast should('contain', 'coś') – i test pada na białych znakach

• Brak zagnieżdżeń (.and()) i chaotyczne powtarzanie get().should()