Să ne scufundăm în Cypress pentru teste end-to-end

Acest articol a fost sponsorizat de dragii noștri prieteni de la LambdaTest, care fac experiența de testare între browsere mai ușoară pentru atât de mulți oameni de pe tot globul. Mulțumesc!

Dezvoltarea de software fără testare automată este greu de imaginat astăzi. O bună varietate de proceduri de testare diferite va asigura un nivel ridicat de calitate. Ca bază pentru testare, putem folosi o serie de teste unitare. Pe deasupra, în mijlocul piramidei, ca să spunem așa, sunt teste de integrare. Testele end-to-end sunt la vârf, acoperind cele mai critice cazuri de utilizare. Acest al treilea tip de testare va fi punctul central al acestui articol.

Cu toate acestea, testarea end-to-end are unele capcane care sunt motive de îngrijorare:

• Testele end-to-end sunt lente și, prin urmare, reprezintă un obstacol semnificativ în fiecare strategie de integrare continuă și implementare continuă (CI/CD). Nu numai asta, ci imaginați-vă că finalizați o sarcină, o funcție sau orice altă implementare - așteptarea executării testului poate epuiza răbdarea tuturor.
• Astfel de teste end-to-end sunt greu de întreținut, predispuse la erori și costisitoare din toate punctele de vedere, datorită efortului de depanare. Diferiți factori pot cauza acest lucru. Testul tău ar trebui să se simtă ca un asistent, niciodată un obstacol.
• Cel mai mare coșmar pentru dezvoltatori este un test fulger, care este un test care se execută în același mod, dar duce la rezultate diferite. Este ca un „Heisenbug”, care apare doar dacă nu măsori aplicația testată – adică dacă nu te uiți la ea.

Dar nu-ți face griji: nu trebuie să cedezi acestor capcane. Să vedem cum să prevenim multe dintre ele . Cu toate acestea, nu voi promite doar luna și nu voi livra. În acest ghid, vom scrie împreună câteva teste, pe care le-am făcut publice pentru dvs. într-un depozit GitHub. În acest fel, sper să vă arăt că testarea finală poate fi distractivă! Să începem.

Ce sunt testele end-to-end?

Când vorbesc despre testarea end-to-end (sau E2E), îmi place să mă refer la aceasta ca fiind „bazată pe fluxul de lucru”. Expresia rezumă bine testarea de la capăt la capăt: simulează fluxurile de lucru reale ale utilizatorilor și ar trebui să includă cât mai multe zone funcționale și părți ale stivei de tehnologie utilizate în aplicație. În cele din urmă, computerul se preface a fi un client și încearcă să se comporte ca un utilizator real. Aceste teste sunt cele mai bune pentru aplicarea unui stres constant asupra întregului sistem al aplicației dvs. și, prin urmare, sunt o măsură excelentă pentru a asigura calitatea atunci când întreaga stivă de aplicații este prezentă.

Să ne amintim ce vrem să realizăm cu toate acestea. Știm că testarea front-end este un set de practici pentru testarea interfeței de utilizare a unei aplicații web, inclusiv a funcționalității acesteia. Are sens — cu aceste măsuri, ne putem asigura că aplicația noastră funcționează corect și că nicio modificare viitoare nu va rupe codul nostru. Pentru a realiza acest lucru eficient, s-ar putea să vă întrebați ce și cât de mult trebuie să testați.

Aceasta este o întrebare validă. S-ar putea să găsiți un răspuns posibil într-o metaforă: piramida de automatizare a testelor, introdusă pentru prima dată de Mike Cohn și specificată în continuare de Martin Fowler, arată cum să eficientizați testarea . Găsim teste unitare rapide și ieftine la cel mai de jos nivel al piramidei și teste de UI (testare end-to-end) consumatoare de timp și costisitoare în partea de sus.

Explicarea acestui lucru și a avantajelor și dezavantajelor sale ar fi suficientă pentru propriul articol. Aș dori să mă concentrez pe un singur nivel. Testele end-to-end, în special, pot aduce îmbunătățiri semnificative ale calității dacă sunt prioritizate în mod eficient. Procedând astfel, ne putem pune constant sistemul sub stres și ne putem asigura că funcțiile principale ale aplicației noastre funcționează corect.

Călătoria mea spre Cypress

Când am început să învăț cum să scriu teste end-to-end, am folosit Mink, o bibliotecă PHP, pe lângă Behat, un cadru de dezvoltare bazată pe comportament (BDD) orientat pe scenarii. Am început să folosesc seleniul, cu toate avantajele și dezavantajele sale. Deoarece echipa mea a început să lucreze mult cu Vue.js, am trecut la un cadru de testare bazat pe JavaScript pentru a asigura o integrare și compatibilitate perfecte. Alegerea noastră pe atunci a fost Nightwatch.js, așa că am construit noua noastră suită de teste de la zero.

În acest timp, am întâlnit adesea probleme de compatibilitate . L-ați putea numi iadul dependenței – ca să nu mai vorbim de toate limitările pe care le-am văzut cu Selenium și mai târziu cu WebDriver.

• În echipa noastră, nu am reușit să identificăm versiunea Chrome a CI. Deci, dacă au fost lansate actualizări pentru Chrome, Nightwatch.js nu a fost suficient de rapid pentru a fi compatibil, provocând multe eșecuri în conductele noastre de testare.
• Numărul de cauze ale testelor necompletate a început să crească, deoarece posibilitățile de așteptare ale Nightwatch.js nu se potriveau optim cu produsul nostru.

Așadar, am ajuns să ne gândim să construim din nou suita noastră de teste. După ce am vizitat o neconferință, am descoperit Cypress.

Cypress este un cadru de testare all-in-one care nu utilizează Selenium sau WebDriver. Instrumentul folosește Node.js pentru a porni un browser sub control special. Testele din acest cadru sunt rulate la nivel de browser, nu doar prin control de la distanță. Asta oferă mai multe avantaje.

Pe scurt, iată motivele pentru care am ales acest cadru:

• Capacitate excelentă de depanare
  Runnerul de testare al lui Cypress poate sări înapoi la orice stare a aplicației prin instantanee. Deci, putem vedea direct o eroare și toți pașii înaintea acesteia. În plus, există acces deplin la instrumentele pentru dezvoltatori Chrome (DevTools), iar clicurile sunt înregistrate complet.
• Modalități mai bune de a aștepta acțiuni în test sau UI sau în răspunsurile de la API
  Cypress aduce implicit așteptare, deci nu este nevoie de verificări adecvate. De asemenea, puteți face ca testul să aștepte animații și răspunsuri API.
• Testele sunt scrise în JavaScript
  Acest lucru atenuează curba de învățare pentru a scrie teste. Runnerul de testare al lui Cypress este open-source, așa că se potrivește strategiei noastre de produs.

Cu toate acestea, acest articol este un ghid, așa că să ne oprim cu aceste informații generale și să începem.

Noțiuni de bază

Instalați și porniți Cypress

Să începem de la zero. În discuțiile mele despre Cypress, de obicei încep prin a crea un nou director prin mkdir și apoi instalez imediat Cypress. Cel mai simplu mod de instalare este prezentat în acest desen:

Un mic indiciu: dacă nu doriți să utilizați npm, puteți instala Cypress prin Yarn:

 yarn add cypress --dev

O alternativă este descărcarea directă, folosind folderele ZIP pe care Cypress le oferă. Asta e! Odată ce instalarea este finalizată, sunteți gata să începeți.

Există două moduri de a începe să rulați teste Cypress. Primul este pornind Cypress în consolă și rulând testele fără cap:

 ./node_modules/.bin/cypress run

A doua modalitate este să utilizați una dintre caracteristicile îngrijite ale lui Cypress, care este sistemul său de testare integrat. Runnerul de testare este o interfață de utilizare pentru rularea testelor. Pentru a-l lansa, puteți folosi o comandă similară:

 ./node_modules/.bin/cypress open

Această comandă va deschide runnerul de testare. Când deschideți Cypress pentru prima dată, veți vedea această interfață:

Cypress oferă câteva exemple de teste prescrise pentru a-și prezenta caracteristicile și pentru a vă oferi câteva puncte de plecare - acesta este motivul pentru testele care sunt disponibile. Să le ignorăm deocamdată, pentru că vrem să le scriem pe a noastră în curând. Cu toate acestea, vă rugăm să țineți cont de această zonă „Teste de integrare”, deoarece va explica o mare parte din magia care se va întâmpla mai târziu.

Prima impresie asupra structurii chiparoșului

Acum este timpul să deschidem proiectul nostru nou creat în mediul de dezvoltare integrat (IDE) la alegere. Dacă navigați la acest folder, veți vedea următoarea structură de testare:

 smashing-example └── cypress └── fixtures └── integration └── plugins └── support └── cypress.json

Să trecem peste aceste foldere:

• fixtures
  Aici veți găsi date de testare fixe, care nu au nicio legătură cu celelalte entități. Deci, nu sunt stocate ID-uri aici, care se pot schimba în funcție de statul local.
• integration
  Testele reale le veți găsi aici.
• plugins
  Aici, puteți extinde Cypress, fie cu pluginuri Cypress existente, fie cu propriile dvs.
• support
  Aici, puteți extinde Cypress în sine. Propriile comenzi și ajutoare se află aici.
• cypress.json
  Modificați aici configurațiile, inclusiv pentru mediu.

În regulă, cred că ne putem găsi drumul în jurul Cypress acum, fie că este cel care rulează de testare, fie că este codul sursă. Dar cum începem? Ce vrem să testăm?

Alege un caz de testare

Un test tipic end-to-end poate deveni complex, mai ales dacă are o mulțime de pași. Ar fi nevoie de mult timp pentru a se executa manual. Din cauza acestei complexități, testele E2E pot fi dificil de automatizat și lent de rulat. Ca rezultat, trebuie să decidem cu atenție ce cazuri să automatizăm.

În opinia mea, termenul „bazat pe fluxul de lucru” este cheie : am selecta cazuri de testare pe baza poveștilor tipice ale utilizatorilor. Cu toate acestea, din cauza timpilor de rulare, nu este recomandabil să acoperiți fiecare flux de lucru disponibil. Prin urmare, avem nevoie de o modalitate de a prioritiza cazurile noastre de testare.

În echipa mea, am avut mai multe criterii pentru proiectul nostru. Cazul de testare ar trebui:

• acoperă cele mai generale și mai utilizate fluxuri de lucru ale unei caracteristici, cum ar fi operațiunile CRUD (termenul „cale fericită” descrie destul de bine aceste fluxuri de lucru);
• utilizați analiza de risc, acoperind fluxurile de lucru cu teste E2E care sunt cele mai vulnerabile (adică acolo unde erorile ar cauza cele mai multe daune);
• evitați acoperirea dublată;
• nu poate fi utilizat neapărat dacă testele unitare sunt mai adecvate (utilizați un test E2E pentru a testa răspunsul software-ului dvs. la o eroare, nu eroarea în sine).

Al doilea lucru cel mai important de reținut este să testați doar fluxul de lucru pe care doriți să îl testați în mod explicit. Toți ceilalți pași necesari pentru ca testarea să funcționeze ar trebui să fie efectuate cu operațiuni API în afara testului, pentru a evita testarea acestora. În acest fel, veți asigura durate minime de rulare a testului și veți obține un rezultat clar al cazului dvs. de testare dacă nu reușește. Gândiți-vă la acest flux de lucru așa cum ar face un utilizator final: concentrați-vă pe utilizarea funcției mai degrabă decât pe implementarea tehnică .

Exemplu:

Dacă doriți să testați procesul de finalizare a comenzii într-un magazin online, nu efectuați toți ceilalți pași, cum ar fi crearea produselor și categoriilor, chiar dacă veți avea nevoie de ele pentru a procesa finalizarea comenzii. Utilizați, de exemplu, un API sau un dump de bază de date pentru a face aceste lucruri și configurați testul doar pentru finalizarea plății.

Exemplu: Găsirea articolelor mele în Smashing Magazine

Vreau să scriu un test pentru acest site, Smashing Magazine. Nu pot garanta că acest test va fi la zi pentru totdeauna, dar să sperăm că va dura. În orice caz, veți putea găsi acest exemplu într-un depozit GitHub.

Crearea primului nostru test de chiparos

În folderul de integration , vom începe prin a crea un fișier nou. Să-i spunem find-author.spec.js . Sufixul .spec înseamnă „specificație”. În ceea ce privește un test, acesta se referă la detaliile tehnice ale unei anumite caracteristici sau aplicații pe care trebuie să le îndeplinească aplicația dvs.

Pentru a transforma acest fișier JavaScript gol într-o casă de testare, vom începe prin a oferi suita de teste structura sa. Vom folosi metoda numită describe . describe() sau context() este folosit pentru a conține și a organiza testele. Cu alte cuvinte, această metodă servește drept cadru pentru testele noastre. Astfel, fișierul nostru de testare va arăta astfel:

 // find-author.spec.js describe('Find authors at smashing', () => { //... });

Următorul pas este crearea testului propriu-zis. Vom folosi metoda it it() , sau specify() , este folosit pentru a reprezenta testul real. După cum puteți vedea, putem captura mai multe teste într-un singur fișier, ceea ce permite câteva opțiuni excelente de structurare.

 // find-author.spec.js describe('Find authors at smashing', () => { it('Find the author Ramona Schwering', () => { cy.log('This is our brand-new test'); }); });

Mic indiciu : Dacă sunteți familiarizat cu Mocha, este posibil să fi observat unele asemănări. Cypress este construit pe deasupra lui Mocha, deci sintaxa este aceeași.

În regulă, să continuăm. Dacă rulăm testul în testul lui Cypress, vom observa că Cypress va deschide un browser pentru a rula testul. Acest browser este văzut în captura de ecran de mai jos:

Felicitări! Am scris primul nostru test! Sigur, nu face mare lucru. Trebuie să continuăm. Să ne umplem testul cu viață.

Umple testul cu viață

Care este primul lucru de făcut când testați un site web? Corect, trebuie să deschidem site-ul. Putem face asta folosind o comandă Cypress. Care este comanda, s-ar putea să vă întrebați?

Lucrul cu comenzi

Există în principal două tipuri de instrucțiuni utilizate într-un test E2E. Primul tip de instrucțiune, comenzile, reprezintă pașii individuali din test. În contextul Cypress, comenzile sunt tot ceea ce face Cypress pentru a interacționa cu site-ul dvs. web. Această interacțiune poate fi orice - un clic, derularea în jos a site-ului web sau chiar găsirea unui element. Drept urmare, comenzile vor fi unul dintre lucrurile importante cu care ne vom completa testul.

Așadar, prima noastră comandă va fi cea de navigare la site-ul web — smashingmagazine.com . Această comandă se numește visit .

Folosind-o, testul nostru va arăta astfel:

 // find-author.spec.js describe('Find authors at smashing', () => { it('Find the author Ramona Schwering', () => { cy.visit('https://www.smashingmagazine.com/'); }); });

Există o comandă pe care o folosesc des - și o vei face și tu. Se numește get :

 cy.get('selector');

Această comandă returnează un element în funcție de selectorul său - similar cu $(…) al jQuery. Deci, ați folosi această comandă pentru a găsi părțile cu care să interacționați. De obicei, l-ați folosi pentru a porni un lanț de comenzi. Dar stai — ce se înțelege prin lanț de comenzi?

După cum s-a menționat la începutul acestui articol, toate testele și tot ceea ce este însoțit de ele sunt scrise în JavaScript. Poți pune comenzile din teste (adică enunțurile) într-un lanț (înlănțuit, cu alte cuvinte). Aceasta înseamnă că comenzile pot transmite un subiect (sau valoarea returnată) a unei comenzi la următoarea comandă, așa cum știm din multe cadre de testare.

În regulă, vom începe un lanț de comenzi cu comanda get . Pentru a găsi un element cu get , trebuie să găsim mai întâi selectorul acestuia. Găsirea unui selector unic este esențială, deoarece Cypress ar returna, altfel, toate elementele care se potrivesc; deci, țineți cont de acest lucru și evitați-l dacă nu este intenționat.

Interacțiunea cu elementele

Cypress în sine are o caracteristică care vă ajută să găsiți selectorii elementelor cu care doriți să lucrați. Această caracteristică se numește Selector Playground și vă ajută să descoperiți selectori unici ai unei componente sau să vedeți toate elementele care se potrivesc pentru un selector sau un șir de text. Deci, această caracteristică vă poate ajuta foarte mult în această sarcină. Pentru a-l activa, faceți clic pe pictograma încrucișată din antetul interfeței de utilizare a testului, apoi plasați cursorul peste elementul dorit:

După cum se vede în captura de ecran de mai sus, un sfat explicativ va afișa selectorul la trecerea cursorului sau în această bară mică de sub pictograma încrucișată, care a apărut când a fost făcut clic pe element. În această bară, puteți vedea, de asemenea, câte elemente s-ar potrivi cu selectorul dat - asigurând unicitatea acestuia în cazul nostru.

Uneori, acei selectori generați automat s-ar putea să nu fie cei pe care doriți să le utilizați (de exemplu, dacă sunt lungi sau greu de citit sau nu vă îndeplinesc celelalte criterii). Selectorul generat mai jos este dificil de înțeles și prea lung, după umila mea părere:

În acest caz, m-aș întoarce la DevTools ale browserului pentru a-mi găsi selectorii unici. Este posibil să fiți familiarizat cu aceste instrumente; în cazul meu, aleg adesea Chrome în acest scop. Cu toate acestea, alte browsere acceptate pot oferi caracteristici similare. Procesul este similar cu Selector Playground, cu excepția faptului că folosim funcțiile DevTools din fila „Element”.

Pentru a vă asigura că un selector este unic, vă recomand să îl căutați în vizualizarea codului DevTools. Dacă găsiți un singur rezultat, puteți fi sigur că este unic.

Știați că există multe tipuri diferite de selectoare ? În funcție de varietate, testele pot arăta și chiar se pot comporta destul de diferit. Unele soiuri sunt mai potrivite pentru testarea end-to-end decât altele. Dacă doriți să știți ce selectoare să utilizați pentru a vă menține testele stabile și curate, vă pot indica unul dintre articolele mele care acoperă această problemă. Înșiși dezvoltatorii Cypress oferă câteva îndrumări cu privire la acest subiect în cele mai bune practici.

Testul nostru ca o secvență de comenzi

OK, înapoi la testul nostru. În el, dorim să afișăm fluxul nostru de lucru:

„Eu, ca utilizator, voi căuta articolul autorului și voi naviga la site-ul web al autorului prin zona de referință dintr-unul dintre articolele lor.”

Vom reproduce pașii pe care i-ar face un utilizator utilizând comenzi. Voi lipi mai jos testul terminat cu comentarii, care vor explica pașii:

 // find-author.spec.js it('Find the author Ramona Schwering', () => { // Open the website cy.visit('https://www.smashingmagazine.com'); // Enter author's name in search field cy.get('#js-search-input').type('Ramona Schwering'); // Navigate to author's article cy.get('h2 > a').first().click(); // Open the author's page cy.get('.author-post__author-title').click(); });

Acest exemplu tratează fluxul de lucru pe care dorim să-l testăm. Cypress va executa acest test. Deci, este timpul să spuneți „Felicitări”? Am terminat în sfârșit de scris primul nostru test?

Ei bine, vă rog să aruncați o privire mai atentă . Cypress îl va executa, dar va face doar ceea ce îi spune testul, care este orice ați scris. Dacă îl rulați în runnerul de testare, puteți vedea dacă a trecut, dar nu în cazul în care îl rulați fără cap. Cu acest test, știm doar dacă Cypress a putut rula comenzile cu succes - nu dacă am ajuns pe site-ul web al autorului. Deci, trebuie să ne predăm testul pentru a determina asta.

Lucrul cu aserțiuni

Al doilea tip de declarație are grijă de descrierile stării dorite a UI - adică dacă ceva ar trebui să existe, să fie vizibil sau să nu mai fie vizibil. Afirmațiile din Cypress se bazează pe aserțiuni Chai și Sinon-Chai, ceea ce este vizibil în sintaxă.

Amintiți-vă că vrem să verificăm dacă ne aflăm pe pagina de profil a autorului - a mea în acest exemplu. Deci, trebuie să adăugăm o afirmație pentru exact asta:

 // find-author.spec.js it('Find the author Ramona Schwering', () => { // Open the website cy.visit('https://www.smashingmagazine.com'); // Enter author's name in search field cy.get('#js-search-input').type('Ramona Schwering'); // Navigate to author's article cy.get('h2 > a').first().click(); // Open the author's page cy.get('.author-post__author-title').click(); // Check if we're on the author's site cy.contains('.author__title', 'Ramona Schwering').should('be.visible'); });

Bine, acum am scris un test care are valoare. Deci, da, felicitări pentru că ai scris primul tău test... chiar dacă nu este încă perfect.

Să ne facem testul drăguț

Chiar dacă am reușit să scriem un prim test semnificativ și am învățat conceptul de bază în acest proces, nu l-aș îmbina încă pe acesta dacă ar fi propus într-o cerere de extragere. Mai sunt câteva lucruri de făcut pentru a o face să strălucească.

Nu vă grăbiți

Cypress are o opțiune de reîncercare încorporată în aproape fiecare comandă, așa că nu trebuie să așteptați să vedeți dacă, de exemplu, există deja un element. Cu toate acestea, aceasta caută doar să vadă dacă un element există în DOM, nu mai mult decât atât. Cypress nu poate prezice tot ce face aplicația dvs., așa că ar putea exista o oarecare slăbiciune dacă vă bazați exclusiv pe acest lucru.

Ce ar face un utilizator dacă ar dori să vadă un site web care încă se încarcă? Cel mai probabil ar aștepta până când unele părți ale site-ului web devin vizibile (astfel, încărcate) și apoi ar interacționa cu ele. În testul nostru, vrem să imităm exact asta: vrem să așteptăm modificări în interfața de utilizare înainte de a începe să interacționăm . În cele mai multe cazuri, am limita acest comportament la elementele de care avem nevoie, utilizând astfel afirmații asupra acestor elemente.

După cum puteți vedea, trebuie să facem testul nostru să aștepte de mai multe ori. Totuși, nici așteptarea de prea multe ori nu este bine. Ca regulă generală, aș sugera să utilizați o afirmație pentru a verifica dacă elementul cu care să interacționați s-a încărcat complet, ca prim pas pentru a determina dacă site-ul web testat s-a încărcat.

Să aruncăm o privire la o astfel de parte a testului nostru ca exemplu. Am adăugat o afirmație pentru a mă asigura că pagina noastră s-a încărcat complet :

 // find-author-assertions.spec.js // Open website cy.visit('https://www.smashingmagazine.com'); // Ensure site is fully loaded cy.get('.headline-content').should('be.visible'); // Enter author's name in the search field cy.get('#js-search-input').type('Ramona Schwering');

Continuați să adăugați afirmații în așa fel în toate cazurile în care site-ul nostru web va avea timpi de încărcare sau mai multe elemente care trebuie redate. Pentru fișierul de testare complet, vă rugăm să priviți testul corespunzător din depozitul GitHub.

Pentru a evita căderea în capcana testelor neconformate, aș dori să vă ofer un ultim indiciu: nu utilizați niciodată timpi de așteptare fix, cum ar fi cy.wait(500) sau altele asemenea.

Răspunsurile API sunt prietenii tăi

Există o posibilitate bună de așteptare, în special, pe care îmi place să o folosesc în testele mele. În Cypress, este posibil să lucrați cu funcții de rețea — un alt mod util de a aștepta în aplicația dvs. este să utilizați aceste funcții pentru a lucra cu solicitările de rețea . În acest fel, puteți face testul să aștepte un răspuns API de succes.

Dacă ne amintim fluxul nostru de lucru ca exemplu, un pas ar putea folosi foarte bine o posibilitate de așteptare API. Mă gândesc la căutare. O poveste de utilizator corespunzătoare ar putea fi următoarea:

„Eu, ca dezvoltator, vreau să mă asigur că rezultatele căutării noastre s-au încărcat complet, astfel încât niciun articol cu ​​rezultate mai vechi să nu inducă în eroare testul nostru.”

Să aplicăm asta testului nostru. În primul rând, trebuie să definim traseul pe care vrem să îl așteptăm mai târziu. Putem folosi comanda de intercept pentru asta. Aș căuta cererea, aducând datele de care am nevoie - rezultatele căutării în acest caz.

Pentru a menține acest exemplu simplu, voi folosi un wildcard pentru adresa URL. După aceea, voi folosi un alias, astfel încât Cypress să poată lucra cu această rută mai târziu.

 // find-author-hooks.spec.js // Set the route to work with it('Find the author Ramona Schwering', () => { // Route to wait for later cy.intercept({ url: '*/indexes/smashingmagazine/*', method: 'POST' }).as('search'); // With this alias Cypress will find the request again //...

În Cypress, toate rutele definite sunt afișate la începutul testului. Deci, aș dori să pun acele comenzi de intercept și la începutul testului meu.

Acum, putem folosi acest alias de rută în aserțiuni. Cea mai simplă modalitate de a face acest lucru ar fi cu comanda wait a lui Cypress, direct cu aliasul menționat anterior. Cu toate acestea, utilizarea singură a acestei comenzi ar duce la așteptarea răspunsului, indiferent de rezultatul acestuia . Chiar și codurile de eroare, cum ar fi 400 sau 500, ar fi luate în considerare, în timp ce aplicația dvs. s-ar rupe cel mai probabil. Așa că aș recomanda să adăugați o altă afirmație ca aceasta:

 // find-author-hooks.spec.js // Later: Assertion of the search request's status code cy.wait('@search') .its('response.statusCode').should('equal', 200);

Astfel, putem aștepta datele software-ului, modificările și așa mai departe cu precizie, fără să pierdem timp sau să intrăm în probleme dacă aplicația este puternic stresată. Din nou, puteți găsi fișierul exemplu complet în depozitul meu GitHub.

Configurarea Cypress

Am omis un mic detaliu. Dacă aruncați o privire mai atentă la exemplul de test complet, acesta diferă ușor de cele pe care le-am folosit aici în acest ghid.

 // Cypress describe('Find author at smashing', () => { beforeEach(() => { // Open website cy.visit('https://www.smashingmagazine.com'); }); //...

Folosesc doar o bară oblică pentru a deschide site-ul revistei Smashing Magazine. Cum funcționează? Ei bine, folosind această comandă astfel, veți naviga la baseUrl -ului testelor noastre. baseUrl este o valoare de configurare care poate fi folosită ca prefix pentru adresa URL a comenzii cy.visit() sau cy.request() . Printre alte valori, putem defini această valoare în fișierul cypress.json . Pentru testul nostru, vom seta baseUrl astfel:

 // cypress.json { "baseUrl": "https://www.smashingmagazine.com" }

Mențiune de onoare: Hooks

A mai rămas un subiect pe care vreau să-l menționez, chiar dacă exemplul nostru de test nu este potrivit pentru utilizare. Așa cum este obișnuit în alte cadre de testare, putem defini ce se întâmplă înainte și după testele noastre prin așa-numitele cârlige ale ciclului de viață. Mai precis, acestea există pentru a executa cod înainte sau după unul sau toate testele:

 // Cypress describe('Hooks', function() { before(() => { // Runs once before all tests }); after(() => { // Runs once after all tests }); beforeEach(() => { // Runs before each test }); afterEach(() => { // Runs after each test }); });

Dorim să umplem fișierul nostru de testare cu mai multe teste, așa că ar trebui să căutăm pași comuni pe care dorim să-i executăm înainte sau după ei. Prima noastră linie este un exemplu, fiind comanda de visit . Presupunând că dorim să deschidem acest site web înainte de fiecare dintre aceste teste, un beforeEach hook din exemplul nostru ar arăta astfel:

 // Cypress describe('Find author at smashing', () => { beforeEach(() => { // Open website cy.visit('https://www.smashingmagazine.com'); }); //... 

Folosesc frecvent acest lucru în munca mea zilnică pentru a mă asigura, de exemplu, că aplicația mea este resetată la starea implicită înainte de testare , izolând astfel testul de alte teste. ( Nu vă bazați niciodată pe testele anterioare! ) Rulați testele izolat unul de celălalt pentru a menține controlul asupra stării aplicației.

Fiecare test ar trebui să poată rula singur - independent de alte teste. Acest lucru este esențial pentru a asigura rezultate valide ale testelor . Pentru detalii despre aceasta, consultați secțiunea „Date pe care obișnuiam să le partajăm” într-unul dintre articolele mele recente. Pentru moment, consultați exemplul complet de pe GitHub dacă doriți să vedeți întregul test.

Concluzie

În opinia mea, testele end-to-end sunt o componentă esențială a CI, menținând calitatea aplicațiilor la un nivel ridicat și în același timp ușurând munca testerilor. Cypress este instrumentul meu preferat pentru depanarea rapidă, stabilă și eficientă a testelor end-to-end și pentru a le rula în paralel cu orice cerere de extragere ca parte a CI. Curba de învățare este blândă dacă sunteți deja familiarizat cu JavaScript.

Sper că v-am putut ghida puțin și v-am dat un punct de plecare pentru a scrie teste Cypress și câteva sfaturi practice pentru a începe. Desigur, toate exemplele de cod sunt disponibile în depozitul GitHub, așa că nu ezitați să aruncați o privire.

Desigur, acesta este doar un punct de plecare; mai sunt multe lucruri de învățat și de discutat cu privire la testele Cypress — vă las cu câteva sugestii despre ce să învățați în continuare. Având în vedere acest lucru, testare fericită!

Resurse

• Exemplu zdrobitor original, Ramona Schwering
  Depozitul GitHub pentru exemplul din acest articol.
• Documentație Cypress
• „Rețete”, Chiparos
  O selecție de exemple, rețete și cursuri.
• „Învățați să codificați cu JavaScript: Cypress” (lecție), CodeLikeThis
• Cele mai bune practici pentru scrierea testelor end-to-end”, Shopware Docs