Cypres-påstand: 9 fakta, du bør vide

Cypress Assertion hjælper os med at hævde en bestemt Assertion er valideringstrin, der sikrer, om det forventede resultat er lig med det faktiske resultat. I testautomatisering hævder vi en erklæring for at bekræfte, at testen genererer det forventede resultat. Hvis påstanden mislykkes, så mislykkes testcasen og sikrer, at der er en fejl. I denne artikel vil vi diskutere om Cypress Assertion med Handson implementering og eksempler.

Indholdsfortegnelse

Cypres påstand

Hvad er Cypress Assertion?

Cypress bruger og omslutter Chai påstandsbibliotek og udvidelser som Sinon og JQuery. Cypress venter automatisk og prøver igen, indtil påstanden er løst. Påstande kan bruges til at beskrive, hvordan applikationen skal se ud. Vi kan bruge Cypress-påstande med en kombination af ventetider, prøv igen, bloker, indtil den når den ønskede tilstand.

Cypres hævde tekst

På generelt engelsk vil vi beskrive en påstand noget som, Jeg forventer, at knappen har login-tekst. Den samme påstand kan skrives i Cypress som

cy.get('button').should('have.value', 'login')

Ovenstående påstand vil bestå, hvis knappen har 'login'-værdi.

Cypres almindelige påstande

Der er et sæt almindelige Cypress-påstande, som vi bruger i vores testcases. Vi vil bruge dem med .should() . Lad os se nærmere på use casen og eksemplerne.

Nogle af de almindelige Cypress-påstande er anført nedenfor

  1. Længde
  2. Værdi
  3. Tekst kontekst
  4. Klasse
  5. Eksistens
  6. CSS
  7. Synlighed
  8. Tilstand
  9. Deaktiveret ejendom

Cypreslængdepåstand

length() vil kontrollere, om det bestemte element har længde

cy.get('dropdown').should('have.length', 5)

Cypres værdiangivelse

Cypress-værdien vil hævde, hvis det bestemte element har den forventede værdi

cy.get('textfield').should('have.value', 'first name')

Cypres tekstkontekstpåstand

Tekstkontekst vil hævde, hvis elementet har den bestemte tekst

cy.get('#user-name').should('have.text', 'John Doe')

Cypres klassepåstand

Angiver, om klassen er til stede, eller det bestemte element skal have klassen

cy.get('form').find('input').should('have.class', 'disabled')

Cypres eksistenspåstand

Eksistenskommando kontrollerer, om det bestemte element er til stede eller findes i DOM eller ej

cy.get('#button').should('exist')

Cypress CSS Assertion

CSS Assertion kontrollerer, om de bestemte elementer har en bestemt egenskab

cy.get('.completed').should('have.css', 'text-decoration', 'line-through')

Cypres synlighedspåstand

Cypress Visibility Assertion fastslår, om DOM-elementet er synligt i brugergrænsefladen

cy.get('#form-submit').should('be.visible')

Cypress State Assertion

Bekræfter DOM-elementets tilstand

cy.get(':radio').should('be.checked')

Cypress Disabled Property Assertion

Cypress Disabled-egenskabspåstand hævder, om elementet er deaktiveret

cy.get('#example-input').should('be.disabled')

Cypres Prøv igen påstand

En enkelt kommando efterfulgt af en påstand udføres i rækkefølge. Indledningsvis udføres kommandoen, og derefter udføres påstanden. En enkelt kommando efterfulgt af flere påstande vil også udføres i rækkefølge - henholdsvis første og anden påstand. Så når den første påstand passerer, vil den første og den anden påstand blive udført sammen med kommandoerne igen.

For eksempel indeholder nedenstående kommando begge dele .should() , .and() påstandskommandoer, hvor .and() er ellers kendt som .should()

cy.get('.todo-list li') // kommando .should('have.length', 2) // assertion .and(($li) => { // 2 flere påstande forventer($li.get) (0).textContent, 'first item').to.equal('todo A') expect($li.get(1).textContent, 'second item').to.equal('todo B') })

Cypres påstand eksempler

I dette afsnit vil vi diskutere de forskellige typer af påstande i Cypress som f.eks

  • Implicit påstand
  • Eksplicit påstand

Vi vil se nærmere på begge typer med eksempler

Implicit påstand i Cypres

I implicit påstand bruger vi .should() or .and() kommandoer. Disse påstandskommandoer gælder for det aktuelle emne i kommandokæden. De er afhængige af det tidligere afgivne emne.

Vi vil se på et eksempel på, hvordan du bruger .should() or .and() kommandoer

cy.get('button').should('have.class', 'enabled')

Med .and() som er et alias af .should() , vi kan kæde flere påstande. Disse kommandoer er mere læsbare.

cy.get('#title') .should('have.class', 'active') .and('have.attr', 'href', '/post')

Ovenstående eksempel er kædet sammen med .should() angiver, at den skal have klassen "aktiv", efterfulgt af .and() udføres mod samme kommando. Dette er meget nyttigt, når vi ønsker at hævde flere kommandoer.

Eksplicit påstand i Cypres

At bestå eksplicit emne i påstandene falder ind under den eksplicitte type Cypress-påstand. Her vil vi bruge expect , assert kommandoer som påstand. Eksplicitte påstande bruges, når vi ønsker at bruge flere påstande for det samme emne. Vi bruger også eksplicit påstand i Cypres, når vi vil lave skik logik før påstanden.

Vi vil se nærmere på eksempel for eksplicit Cypres påstand

expect(true).to.be.true //checker for en boolesk expect(object).to.equal(object)

Negativ Cypres påstand

I lighed med positive påstande er der negative påstande i Cypress. Vi vil bruge "ikke" nøgleord tilføjet til præfikset for påstandserklæringen. Lad os se et eksempel på negativ påstand

cy.get('#loading').should('not.be.visible')

Negativ påstand anbefales kun i tilfælde for at verificere, at en bestemt tilstand ikke længere er tilgængelig, efter at en specifik handling er udført af applikationen.

Lad os f.eks. overveje, at en toggle er markeret og kontrollere, at den er blevet fjernet

// først markeres elementet som afsluttet cy.contains('li.todo', 'Skriv test') .should('have.class', 'completed') .find('.toggle') .click() / / CSS-klassen er blevet fjernet cy.contains('li.todo', 'Skriv test').should('not.have.class', 'completed')

Cypress Custom Assertion Message

Med Cypress kan vi give yderligere information eller tilpasset besked til påstande ved at bruge et bibliotek af matchere. Matchere består af små funktioner, der adskiller værdier og sender en detaljeret fejlmeddelelse. Chai Assertion-biblioteket vil hjælpe vores kode til at se mere læsbar ud og testfejl meget nyttig

const expect = require('chai').expect it('checks a number', () => { const value = 10 const expected = 3 expect(value).to.equal(expected) })
cyyy
Cypress Custom fejlmeddelelse

Best Practices for Cypress Assertion

Vi kan skrive flere påstande i en enkelt blok ved at bruge en kæde af kommandoer. Det er ikke nødvendigt at skrive en enkelt påstand som i enhedstests. Mange skriver påstande som nedenfor. Det er okay at skrive på den måde, men det øger kodelinjen og redundansen.

describe('min formular', () => { før(() => { cy.visit('/users/new') cy.get('#first').type('ashok') }) it( 'har valideringsattribut', () => { cy.get('#first').should('have.attr', 'data-validation', 'required') // anfører, om #first har et obligatorisk felt } ) it('har aktiv klasse', () => { cy.get('#first').should('have.class', 'active') // hævder, om #first har aktiv klasse }) it( 'har formateret fornavn', () => { cy.get('#first').should('have.value', 'Ashok') // påstand om, hvorvidt #first har stort første bogstav }) })

Som du ser ovenfor, bliver den samme vælger- og påstandstype gentaget. I stedet kan vi sammenkæde disse kommandoer i en enkelt påstand, som udfører alle kontroller på en lineær måde.

describe('min formular', () => { før(() => { cy.visit('/users/new') }) it('validerer og formaterer fornavn', () => { cy.get ('#first') .type('ashok') .should('have.attr', 'data-validation', 'required') .and('have.class', 'active') .and('have .value', 'Ashok') }) })

Som nævnt ovenfor kan vi kæde den enkelte vælger med flere påstande! Dette er en af ​​de anbefalede bedste fremgangsmåder til at skrive påstand i Cypress.

Klik på for at forstå sideobjektmodellen i Cypress her.