Prezentare generală de 1.000 de picioare despre scrierea testelor Cypress #frontend@twiliosendgrid

Publicat: 2020-10-03

La Twilio SendGrid, am scris sute de teste Cypress end-to-end (E2E) și continuăm să scriem mai multe pe măsură ce noi funcții sunt lansate în diferite aplicații web și echipe. Aceste teste acoperă întreaga stivă, verificând că cele mai frecvente cazuri de utilizare prin care ar trece un client încă funcționează după ce a introdus noi modificări de cod în aplicațiile noastre.

Dacă doriți mai întâi să faceți un pas înapoi și să citiți mai multe despre cum să vă gândiți la testarea E2E în general, nu ezitați să consultați această postare pe blog și să reveniți la aceasta după ce sunteți gata. Această postare pe blog nu necesită să fiți un expert în testele E2E, dar vă ajută să obțineți starea de spirit potrivită, deoarece veți vedea de ce am făcut lucrurile într-un anumit fel în testele noastre. Dacă sunteți în căutarea unui tutorial mai pas cu pas care să vă prezinte testele Cypress, vă recomandăm să consultați documentele Cypress . În această postare pe blog, presupunem că este posibil să fi văzut sau scris multe teste Cypress înainte și sunteți curioși să vedeți cum scriu alții teste Cypress pentru propriile aplicații.

După ce ați scris o mulțime de teste Cypress, veți începe să vă observați că utilizați funcții, afirmații și modele similare Cypress pentru a realiza ceea ce aveți nevoie. Vă vom arăta cele mai comune părți și strategii pe care le-am folosit sau le-am făcut înainte cu Cypress pentru a scrie teste în medii separate, cum ar fi dev sau staging. Sperăm că această prezentare generală de 1.000 de picioare a modului în care scriem testele Cypress vă oferă idei de comparat cu ale dvs. și vă ajută să îmbunătățiți modul în care abordați testele Cypress.

Contur:

  1. Breviar Cypress API
  2. Interacțiunea cu elementele
  3. Afirmarea asupra elementelor
  4. Se ocupă de API-uri și servicii
  5. Efectuarea de solicitări HTTP cu cy.request(…)
  6. Crearea de pluginuri reutilizabile cu cy.task()
  7. Batjocorirea cererilor de rețea cu cy.server() și cy.route()
  8. Comenzi personalizate
  9. Despre obiectele paginii
  10. Alegerea de a nu rula codul clientului cu window.Cypress verificări
  11. Se ocupă de cadrele iframe
  12. Standardizarea în mediile de testare

Cypress API Roundup

Să începem prin a parcurge părțile pe care le-am folosit cel mai frecvent cu Cypress API.

Selectarea elementelor

Există multe modalități de a selecta elementele DOM, dar puteți realiza cea mai mare parte a ceea ce trebuie să faceți prin aceste comenzi Cypress și, de obicei, puteți înlănțui mai multe acțiuni și afirmații după acestea.

  • Obținerea de elemente bazate pe un selector CSS cu cy.get(“[data-hook='someSelector']”) sau cy.find(“.selector”) .
  • Selectarea elementelor pe baza unui text, cum ar fi cy.contains(“someText”) sau obținerea unui element cu un anumit selector care conține un anumit text, cum ar fi cy.contains(“.selector”, “someText”) .
  • Obținerea unui element părinte să arate „înăuntru”, astfel încât toate interogările viitoare vor fi acoperite la copiii părintelui, cum ar fi cy.get(“.selector”).within(() => { cy.get(“.child”) }) .
  • Găsirea unei liste de elemente și căutarea „fiecare” pentru a efectua mai multe interogări și afirmații, cum ar fi cy.get(“tr”).each(($tableRow) => { cy.wrap($tableRow).find('td').eq(1).should(“contain”, “someText” }) .
  • Uneori, elementele pot fi în afara vizualizării paginii, așa că va trebui să defilați mai întâi elementul în vizualizare, cum ar fi cy.get(“.buttonFarBelow”).scrollIntoView() .
  • Uneori, veți avea nevoie de un timeout mai lung decât timeout-ul implicit al comenzii, așa că puteți adăuga opțional un { timeout: timeoutInMs } precum cy.get(“.someElement”, { timeout: 10000 }) .

Interacțiunea cu elementele

Acestea sunt cele mai utilizate interacțiuni găsite pe parcursul testelor noastre Cypress. Ocazional, va trebui să introduceți o proprietate { force: true } în acele apeluri de funcție pentru a ocoli unele verificări cu elementele. Acest lucru se întâmplă adesea atunci când un element este acoperit într-un fel sau derivat dintr-o bibliotecă externă asupra căreia nu aveți prea mult control în ceea ce privește modul în care redă elemente.

  • Trebuie să facem clic pe multe lucruri, cum ar fi butoanele din modale, tabele și altele asemenea, așa că facem lucruri precum cy.get(“.button”).click() .
  • Formularele sunt peste tot în aplicațiile noastre web pentru a completa detaliile utilizatorului și alte câmpuri de date. Introducem acele intrări cu cy.get(“input”).type(“somekeyboardtyping”) și poate fi necesar să ștergem unele valori implicite ale intrărilor, ștergându-le mai întâi ca cy.get(“input”).clear().type(“somenewinput”) . Există, de asemenea, modalități grozave de a tasta alte taste, cum ar fi {enter} pentru tasta Enter când faceți cy.get(“input”).type(“text{enter}”) .
  • Putem interacționa cu opțiuni selectate precum cy.get(“select”).select(“value”) și casete de selectare precum cy.get(“.checkbox”).check() .

Afirmarea asupra elementelor

Acestea sunt afirmațiile tipice pe care le puteți utiliza în testele dumneavoastră Cypress pentru a determina dacă sunt prezente lucruri pe pagina cu conținutul potrivit.

  • Pentru a verifica dacă lucrurile apar sau nu pe pagină, puteți comuta între cy.get(“.selector”).should(“be.visible”) și cy.get(“.selector”).should(“not.be.visible”) .
  • Pentru a determina dacă elementele DOM există undeva în marcaj și dacă nu vă pasă neapărat dacă elementele sunt vizibile, puteți utiliza cy.get(“.element”).should(“exist”) sau cy.get(“.element”).should(“not.exist”) .
  • Pentru a vedea dacă un element conține sau nu text, puteți alege între cy.get(“button”).should(“contain”, “someText”) și cy.get(“button”).should(“not.contain”, “someText”) .
  • Pentru a verifica o intrare sau un buton este dezactivat sau activat, puteți afirma astfel: cy.get(“button”).should(“be.disabled”) .
  • Pentru a afirma dacă ceva este verificat, puteți testa, cum ar fi, cy.get(“.checkbox”).should(“be.checked”) .
  • De obicei, vă puteți baza pe verificări de text și vizibilitate mai tangibile, dar uneori trebuie să vă bazați pe verificări de clasă precum cy.get(“element”).should(“have.class”, “class-name”) . Există și alte modalități similare de a testa atributele cu .should(“have.attr”, “attribute”) .
  • Este adesea util pentru tine să înlănțuiești și afirmații, cum ar fi cy.get(“div”).should(“be.visible”).and(“contain”, “text”) .

Se ocupă de API-uri și servicii

Când aveți de-a face cu propriile dvs. API-uri și servicii legate de e-mail, puteți utiliza cy.request(...) pentru a face solicitări HTTP către punctele finale de backend cu anteturi de autentificare. O altă alternativă este că puteți crea cy.task(...) care pot fi apelate din orice fișier cu specificații pentru a acoperi alte funcționalități care pot fi gestionate cel mai bine într-un server Node cu alte biblioteci, cum ar fi conectarea la o căsuță de e-mail și găsirea unui potrivirea e-mailului sau a avea mai mult control asupra răspunsurilor și a interogării anumitor apeluri API înainte de a returna unele valori pentru teste.

Efectuarea de solicitări HTTP cu cy.request(…)

Puteți utiliza cy.request() pentru a face solicitări HTTP către API-ul backend pentru a configura sau a demonta datele înainte de a rula cazurile de testare. De obicei, transmiteți adresa URL a punctului final, metoda HTTP, cum ar fi „GET” sau „POST”, anteturi și, uneori, un corp de solicitare de trimis către API-ul backend. Puteți apoi să înlănțuiți acest lucru cu un .then((response) => { }) pentru a obține acces la răspunsul rețelei prin proprietăți precum „status” și „corp”. Un exemplu de efectuare a unui apel cy.request() este demonstrat aici.

Uneori, este posibil să nu vă pese dacă cy.request(...) va eșua sau nu cu un cod de stare 4xx sau 5xx în timpul curățării înainte de rularea unui test. Un scenariu în care puteți alege să ignorați codul de stare eșuat este atunci când testul face o solicitare GET pentru a verifica dacă un articol mai există și a fost deja șters. Este posibil ca articolul să fie deja curățat și solicitarea GET va eșua cu un cod de stare 404 negăsit. În acest caz, ați seta o altă opțiune pentru failOnStatusCode: false , astfel încât testele dumneavoastră Cypress să nu eșueze chiar înainte de a rula pașii de testare.

Crearea de pluginuri reutilizabile cu cy.task()

Când dorim să avem mai multă flexibilitate și control asupra unei funcții reutilizabile pentru a vorbi cu un alt serviciu, cum ar fi un furnizor de căsuțe de e-mail prin intermediul unui server Node (vom acoperi acest exemplu într-o postare de blog ulterioară), ne place să oferim propriile noastre funcționalități suplimentare și Răspunsurile personalizate la apelurile API ne solicită să înlănțuim și să aplicăm în testele noastre Cypress. Sau, ne place să rulăm alt cod pe un server Node - adesea construim un plugin cy.task() pentru acesta. Creăm funcții de plugin în fișierele module și le importăm în plugins/index.ts unde definim pluginurile de sarcini cu argumentele de care avem nevoie pentru a rula funcțiile așa cum se arată mai jos.

Aceste pluginuri pot fi apelate cu un cy.task(“pluginName”, { ...args }) oriunde în fișierele de specificații și vă puteți aștepta să se întâmple aceeași funcționalitate. În timp ce, dacă ați folosit cy.request() , aveți mai puțină reutilizare, cu excepția cazului în care ați împachetat acele apeluri în obiecte de pagină sau fișiere helper care să fie importate peste tot.

O altă avertizare este că, deoarece codul sarcinii pluginului este menit să fie rulat pe un server Node, nu puteți apela comenzile obișnuite Cypress în acele funcții, cum ar fi Cypress.env(“apiHost”) sau cy.getCookie('auth_token') . Transmiteți lucruri precum șirul de jeton de autentificare sau gazda API-ului backend la obiectul argument al funcției dvs. de plugin, în plus față de lucrurile necesare pentru corpul solicitării dacă trebuie să vorbească cu API-ul backend.

Batjocorirea cererilor de rețea cu cy.server() și cy.route()

Pentru testele Cypress care necesită date greu de reprodus (cum ar fi variații ale stărilor importante ale UI pe o pagină sau care se ocupă de apeluri API mai lente), o caracteristică Cypress de luat în considerare este eliminarea solicitărilor de rețea. Acest lucru funcționează bine cu cererile bazate pe XmlHttpRequest (XHR) dacă utilizați vanilla XMLHttpRequest, biblioteca axios sau jQuery AJAX. Apoi veți folosi cy.server() și cy.route() pentru a asculta rute pentru a bate joc de răspunsuri pentru orice stare doriți. Iată un exemplu:

Un alt caz de utilizare este folosirea cy.server() , cy.route() și cy.wait() împreună pentru a asculta și aștepta ca cererile de rețea să se termine înainte de a face pașii următori. De obicei, după încărcarea unei pagini sau după ce facem un fel de acțiune pe pagină, un indiciu vizual intuitiv va semnala că ceva este complet sau gata pentru a ne afirma și a acționa. Pentru cazurile în care nu aveți un indiciu atât de vizibil, puteți aștepta în mod explicit ca un apel API să se termine astfel.

O problemă mare este că, dacă utilizați fetch pentru solicitările de rețea, nu veți putea să bateți joc de solicitările de rețea sau să așteptați ca acestea să se termine în același mod. Veți avea nevoie de o soluție de înlocuire a window.fetch obișnuit cu o umplere polivalentă XHR și de a efectua niște pași de configurare și curățare înainte ca testele să ruleze, așa cum este înregistrat în aceste probleme . Există, de asemenea, o proprietate experimentalFetchPolyfill FetchPolyfill începând cu Cypress 4.9.0 care poate funcționa pentru dvs., dar, în general, încă căutăm metode mai bune pentru a gestiona blocarea rețelei prin utilizarea extragerii și XHR în aplicațiile noastre, fără a se întrerupe lucrurile. Începând cu Cypress 5.1.0, există o nouă funcție promițătoare cy.route2() (a se vedea documentele Cypress ) pentru rețeaua experimentală stubbing atât a XHR, cât și a cererilor de preluare, așa că intenționăm să facem upgrade la versiunea Cypress și să experimentăm cu ea pentru a vedea dacă ne rezolvă problemele.

Comenzi personalizate

Similar cu bibliotecile precum WebdriverIO, puteți crea comenzi personalizate globale care pot fi reutilizate și înlănțuite în fișierele dvs. cu specificații, cum ar fi o comandă personalizată pentru a gestiona conectările prin API înainte de rularea cazurilor de testare. Odată ce le-ați dezvoltat într-un fișier precum support/commands.ts , puteți accesa funcții precum cy.customCommand() sau cy.login() . Scrierea unei comenzi personalizate pentru autentificare arată astfel.

Despre obiectele paginii

Un obiect pagină este un înveliș în jurul selectoarelor și funcțiilor care vă ajută să interacționați cu o pagină. Nu trebuie să construiți obiecte de pagină pentru a vă scrie testele, dar este bine să luați în considerare modalități de a încapsula modificările în interfața de utilizare. Vrei să-ți faci viața mai ușoară în ceea ce privește gruparea lucrurilor pentru a evita actualizarea selectoarelor și a interacțiunilor în mai multe fișiere, mai degrabă decât într-un singur loc.

Puteți defini o clasă de bază „Pagină” cu funcționalitate comună, cum ar fi open() pentru clasele de pagini moștenite de la care să partajați și să vă extindeți. Clasele de pagină derivate își definesc propriile funcții getter pentru selectoare și alte funcții de ajutor în timp ce reutilizează funcționalitatea claselor de bază prin apeluri precum super.open() așa cum se arată aici.

Alegerea de a nu rula codul clientului cu window.Cypress verificări

Când am testat fluxuri cu fișiere cu descărcare automată, cum ar fi un CSV, descărcările ne distrugeau testele Cypress prin înghețarea testului. Ca un compromis, am vrut în principal să testăm dacă utilizatorul ar putea ajunge la starea de succes adecvată pentru o descărcare și să nu descarce efectiv fișierul în testul nostru, adăugând o verificare window.Cypress .

În timpul testării Cypress, va exista o fereastră. Proprietate window.Cypress adăugată browserului. În codul dvs. din partea clientului, puteți alege să verificați dacă nu există nicio proprietate Cypress pe obiectul fereastră, apoi să efectuați descărcarea ca de obicei. Dar, dacă este rulat într-un test Cypress, nu descărcați efectiv fișierul. De asemenea, am profitat de verificarea proprietății window.Cypress pentru experimentele noastre A/B care rulează în aplicația noastră web. Nu am vrut să adăugăm mai multă slăbiciune și comportament nedeterminist din experimentele A/B care ar putea arăta experiențe diferite utilizatorilor noștri de testare, așa că am verificat mai întâi că proprietatea nu este prezentă înainte de a rula logica experimentului, așa cum este evidențiat mai jos.

Se ocupă de cadrele iframe

Tratarea cu iframe poate fi dificilă cu Cypress, deoarece nu există suport încorporat pentru iframe. Există o [issue] ( https://github.com/cypress-io/cypress/issues/136 ) în curs de desfășurare, plină de soluții pentru a gestiona cadrele iframe unice și cadrele iframe imbricate, care pot funcționa sau nu, în funcție de versiunea dvs. curentă de Cypress sau iframe-ul cu care intenționați să interacționați. Pentru cazul nostru de utilizare, aveam nevoie de o modalitate de a trata iframe-urile de facturare Zuora în mediul nostru de pregătire pentru a verifica fluxurile de actualizare a API-ului de e-mail și a campaniilor de marketing. Testele noastre implică completarea eșantionului de informații de facturare înainte de a finaliza o actualizare la o nouă ofertă în aplicația noastră.

Am creat o comandă personalizată cy.iframe(iframeSelector) pentru a încapsula tratarea cu iframe. Trecerea unui selector la iframe va verifica apoi conținutul corpului iframe-ului până când acesta nu mai este gol și apoi va returna conținutul corpului pentru ca acesta să fie legat cu mai multe comenzi Cypress, așa cum se arată mai jos:

Când lucrați cu TypeScript, puteți introduce comanda personalizată iframe astfel în fișierul index.d.ts :

Pentru a realiza partea de facturare a testelor noastre, am folosit comanda personalizată iframe pentru a obține conținutul corpului iframe-ului Zuora și apoi am selectat elementele din cadrul iframe și le-am schimbat direct valorile. Am avut anterior probleme cu utilizarea cy.find(...).type(...) și a altor alternative care nu funcționează, dar, din fericire, am găsit o soluție prin modificarea valorilor intrărilor și selectărilor direct cu comanda invoke, adică cy.get(selector).invoke('val', 'some value') . De asemenea, veți avea nevoie de ”chromeWebSecurity”: false în fișierul de configurare cypress.json pentru a vă permite să ocoliți orice erori de origine încrucișată. Mai jos este oferit un fragment de exemplu de utilizare a acestuia cu selectoare de umplere:

Standardizarea în mediile de testare

După ce am scris teste cu Cypress folosind cele mai comune afirmații, funcții și abordări evidențiate mai devreme, putem rula testele și le facem să treacă într-un singur mediu. Acesta este un prim pas grozav, dar avem mai multe medii pentru a implementa cod nou și pentru a ne testa modificările. Fiecare mediu are propriul set de baze de date, servere și utilizatori, dar testele noastre Cypress ar trebui scrise o singură dată pentru a funcționa cu aceiași pași generali.

Pentru a rula teste Cypress pe mai multe medii de testare, cum ar fi dezvoltarea, testarea și punerea în scenă înainte de a implementa în cele din urmă modificările noastre în producție, trebuie să profităm de capacitatea Cypress de a adăuga variabile de mediu și de a modifica valorile de configurare pentru a sprijini acele cazuri de utilizare.

Pentru a rula testele pe diferite medii frontend :

Va trebui să modificați valoarea „baseUrl” așa cum este accesată prin Cypress.config(“baseUrl”) pentru a se potrivi cu acele adrese URL, cum ar fi https://staging.app.com sau https://testing.app.com . Aceasta modifică adresa URL de bază pentru toate apelurile dvs. cy.visit(...) pentru a le adăuga căile. Există mai multe moduri de a seta acest lucru, cum ar fi setarea CYPRESS_BASE_URL=<frontend_url> înainte de a rula comanda Cypress sau setarea --config baseUrl=<frontend_url> .

Pentru a rula testele pe diferite medii backend :

Trebuie să cunoașteți numele gazdei API, cum ar fi https://staging.api.com sau https://testing.api.com pentru a seta o variabilă de mediu precum „apiHost” și accesată prin apeluri precum Cypress.env(“apiHost”) . Acestea vor fi folosite pentru apelurile dvs. cy.request(...) pentru a face solicitări HTTP către anumite căi precum „<apiHost>/some/endpoint” sau transmise la apelurile dvs. de funcție cy.task(...) ca un alt argument proprietate pentru a ști ce backend să accesați. Aceste apeluri autentificate ar trebui să cunoască, de asemenea, indicativul de autentificare pe care cel mai probabil îl stocați în localStorage sau un cookie prin cy.getCookie(“auth_token”) . Asigurați-vă că acest token de autentificare este transmis în cele din urmă ca parte a antetului „Autorizare” sau prin alte mijloace, ca parte a solicitării dvs. Există o multitudine de moduri de a seta aceste variabile de mediu, cum ar fi direct în fișierul cypress.json sau în opțiunile din linia de comandă --env , unde le puteți referi în documentația Cypress .

Pentru a aborda conectarea la diferiți utilizatori sau utilizarea diferitelor metadate:

Acum că știți cum să gestionați mai multe adrese URL frontend și gazde API backend, cum vă gestionați conectarea la diferiți utilizatori? Cum utilizați metadate variate în funcție de mediu, cum ar fi lucruri legate de domenii, chei API și alte resurse care probabil vor fi unice în mediile de testare?

Să începem cu crearea unei alte variabile de mediu numită „testEnv” cu posibile valori de „testare” și „staging”, astfel încât să puteți folosi acest lucru ca o modalitate de a spune ce utilizatori și metadate ale mediului să le aplicați în test. Folosind variabila de mediu „testEnv”, puteți aborda acest lucru în câteva moduri.

Puteți crea fișiere separate „staging.json”, „testing.json” și alte fișiere JSON de mediu în folderul fixtures și le puteți importa pentru a le utiliza pe baza valorii „testEnv”, cum ar fi cy.fixture(`${testEnv}.json`).then(...) . Cu toate acestea, nu puteți tasta bine fișierele JSON și există mult mai mult loc pentru greșeli în sintaxă și în scrierea tuturor proprietăților necesare testului. Fișierele JSON sunt, de asemenea, mai departe de codul de testare, așa că ar trebui să gestionați cel puțin două fișiere atunci când editați testele. Probleme de întreținere similare ar apărea dacă toate datele de testare de mediu ar fi setate în variabile de mediu direct în cypress.json și ar fi prea multe de gestionat printr-o multitudine de teste.

O opțiune alternativă este de a crea un obiect fix de testare în fișierul de specificații cu proprietăți bazate pe testare sau montaj pentru a încărca utilizatorul și metadatele testului pentru un anumit mediu. Deoarece acestea sunt obiecte, puteți defini, de asemenea, un tip TypeScript generic mai bun în jurul obiectelor dispozitivului de testare pentru ca toate fișierele dvs. de specificații să fie reutilizate și pentru a defini tipurile de metadate. Ați apela Cypress.env(“testEnv”) pentru a vedea cu ce mediu de testare rulați și a utiliza acea valoare pentru a extrage dispozitivul de testare al mediului corespunzător din obiectul general al dispozitivului de testare și a utiliza acele valori în testul dumneavoastră. Ideea generală a obiectului dispozitivelor de testare este rezumată în fragmentul de cod de mai jos.

Aplicarea valorii de configurare Cypress „baseUrl”, a variabilei de mediu backend „apiHost” și a variabilei de mediu „testEnv” împreună ne permite să avem teste Cypress care funcționează împotriva mai multor medii fără a adăuga mai multe condiții sau fluxuri logice separate, așa cum este demonstrat mai jos.

Să facem un pas înapoi pentru a vedea cum poți chiar să faci propriile tale comenzi Cypress să ruleze prin npm. Concepte similare pot fi aplicate pentru fire, Makefile și alte scripturi pe care le utilizați pentru aplicația dvs. Este posibil să doriți să definiți variante ale comenzilor „deschidere” și „executare” pentru a se alinia cu Cypress „deschide” interfața grafică și „a rula” în modul headless împotriva diferitelor medii frontend și backend din package.json . De asemenea, puteți configura mai multe fișiere JSON pentru configurația fiecărui mediu, dar pentru simplitate, veți vedea comenzile cu opțiunile și valorile în linie.

Veți observa în scripturile package.json că „baseUrl” din frontend variază de la „http://localhost:9001” pentru când porniți aplicația local până la adresa URL a aplicației implementate, cum ar fi „ https://staging.app. com ”. Puteți seta variabilele backend „apiHost” și „testEnv” pentru a vă ajuta să faceți solicitări către un punct final de backend și să încărcați un anumit obiect fix de testare. De asemenea, puteți crea comenzi speciale „cicd” pentru atunci când trebuie să rulați testele într-un container Docker cu cheia de înregistrare.

Câteva takeaways

Când vine vorba de selectarea elementelor, interacțiunea cu elementele și afirmarea elementelor de pe pagină, puteți ajunge destul de departe scriind multe teste Cypress cu o listă mică de comenzi Cypress, cum ar fi cy.get() , cy.contains() , .click() ) , .type .type() , .should('be.visible') .

Există, de asemenea, modalități de a face solicitări HTTP către un API de backend folosind cy.request() , de a rula cod arbitrar pe un server Node cu cy.task() și de a elimina cererile de rețea folosind cy.server() și cy.route() . Puteți chiar să vă creați propria comandă personalizată, cum ar fi cy.login() , pentru a vă ajuta să vă conectați la un utilizator prin intermediul API-ului. Toate aceste lucruri ajută la resetarea unui utilizator la punctul de pornire adecvat înainte de rularea testelor. Împachetați aceste selectoare și funcții într-un fișier și ați creat obiecte de pagină reutilizabile pentru a le utiliza în specificațiile dvs.

Pentru a vă ajuta să scrieți teste care trec în mai multe medii, profitați de variabilele de mediu și de obiectele care dețin metadate specifice mediului.

Acest lucru vă va ajuta să rulați seturi diferite de utilizatori cu resurse de date separate în specificațiile Cypress. Comenzile separate Cypress npm, cum ar fi npm run cypress:open:staging package.json pachetul dumneavoastră.json, vor încărca valorile adecvate ale variabilelor de mediu și vor rula testele pentru mediul în care ați ales să rulați.

Aceasta încheie prezentarea noastră de o mie de picioare despre scrierea testelor Cypress. Sperăm că acest lucru v-a oferit exemple practice și modele pe care să le aplicați și să le îmbunătățiți în propriile teste Cypress.

Vrei să afli mai multe despre testele Cypress? Consultați următoarele resurse:

  • Ce să țineți cont atunci când scrieți teste E2E
  • TypeScript Toate lucrurile din testele tale Cypress
  • Confruntarea cu fluxurile de e-mail în testele Cypress
  • Idei pentru configurarea, organizarea și consolidarea testelor dvs. de Cypress
  • Integrarea testelor Cypress cu Docker, Buildkite și CICD