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
- Hvad er Cypress Assertion?
- Cypres hævde tekst
- Cypres almindelig påstand
- Cypres Prøv igen påstand
- Cypres påstand eksempler
- Implicit påstand i Cypres
- Eksplicit påstand i Cypres
- Negativ Cypres påstand
- Cypress Custom Assertion Message
- Best Practices for Cypress Assertion
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
- Længde
- Værdi
- Tekst kontekst
- Klasse
- Eksistens
- CSS
- Synlighed
- Tilstand
- 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) })
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.
Hej...Jeg er Aishwarya Lakshmi, afsluttede min B.Tech og har næsten 2+ års erfaring i testdomænet. Jeg er en testentusiast og brænder for at teste og elsker at udforske nye ting inden for mit felt og dele dem med mine jævnaldrende. Jeg nyder at skrive blogs i min fritid på den enkleste, men effektive måde. Som tester kan jeg godt lide at have tingene til perfektion, så jeg ønsker, at mine læsere har den perfekte forståelse af teknologien. Jeg holder mig opdateret med de nye teknologier relateret til test og bruger tid på at forstå dem. Jeg er glad for at hjælpe eleverne med at forstå begreberne i test.