Există un moment pe care orice tester îl știe bine: deschizi pentru prima dată un proiect React, te uiți la componente, la stare, la re‑render‑uri, și îți zici — "de unde naiba încep să testez asta?" Dacă ești acolo acum, bine ai venit. Rămâi cu noi câteva minute.
Cypress a devenit în ultimii ani unul dintre cele mai iubite tool‑uri de test automation pentru aplicații web moderne, tocmai pentru că a fost gândit cu React, Vue și Angular în minte. Nu e un wrapper pe Selenium 4, nu suferă de sincronizare forțată, și — poate cel mai important pentru un junior — feedback‑ul vizual din browser îți arată exact ce face testul tău, pas cu pas.
Hai să construim împreună drumul de la zero la primul test care rulează în pipeline‑ul echipei tale.
Instalare și configurare — 5 minute, promis
Presupun că ai deja un proiect React generat cu Create React App sau Vite. Deschizi terminalul în folderul proiectului și rulezi:
npm install cypress --save‑dev
Apoi
npx cypress open
La primul start, Cypress îți creează automat structura de foldere: cypress/e2e pentru teste, cypress/fixtures pentru date de test statice, cypress/support pentru comenzi reutilizabile. E un scaffold curat, pe care îl poți păstra sau adapta după nevoile echipei.
Un detaliu pe care mulți îl ratează: în cypress.config.js (sau .ts, dacă ești pe TypeScript), setează baseUrl pe adresa locală a aplicației tale — de obicei http://localhost:3000. Asta îți permite să scrii cy.visit('/') în loc de URL‑ul complet în fiecare test, ceea ce pe termen lung face diferența dintre cod lizibil și cod pe care nu vrei să-l mai atingi.
Selectori — cum îi alegi ca să nu îți pară rău peste două săptămâni
Primul reflex al oricui vine din Selenium este să selecteze elemente după clasă CSS sau după XPath. Rezistă tentației. Clasele se schimbă cu orice redesign, XPath‑ul e fragil și nu îți spune nimic despre intenția testului.
Cypress recomandă atribute data‑cy sau data‑testid adăugate direct în componenta React:
<button data‑cy="submit‑button">Trimite</button>
Iar în test
cy.get('[data‑cy="submit‑button"]').click()
Simplu, stabil, și — cel mai important — comunică intenția: acest element există pentru că testul are nevoie de el. Dacă un coleg developer șterge atributul fără să știe, testul cade imediat și conversația are loc înainte ca bug‑ul să ajungă în producție.
Există și cy.contains() pentru text vizibil, util când testezi mesaje de validare sau etichete dinamice. Și cy.findByRole() dacă folosești Testing Library împreună cu Cypress — o combinație pe care o recomand în special dacă echipa ta pune accent pe accesibilitate.
Primul test end‑to‑end — de la formular la confirmare
Să zicem că aplicația ta are un formular de login. Scenariul clasic: utilizatorul introduce email și parolă, apasă butonul, și vede dashboard‑ul. Iată cum arată testul:
describe('Login flow', () => {
beforeEach(() => {
cy.visit('/login')
})
it('autentifică utilizatorul cu credențiale valide', () => {
cy.get('[data‑cy="email‑input"]').type('test@exemplu.ro')
cy.get('[data‑cy="password‑input"]').type('ParolaSecreta123')
cy.get('[data‑cy="submit‑button"]').click()
cy.url().should('include', '/dashboard')
cy.get('[data‑cy="welcome‑message"]').should('be.visible')
})
})
Observi că nu există niciun await, niciun sleep(), nicio pauză artificială. Cypress așteaptă automat ca elementul să fie prezent în DOM și să fie interactiv înainte să execute comanda. Asta elimină una dintre cele mai frecvente surse de flakiness pe care le vedeai poate în Selenium.
Un sfat din teren: nu testa tot din UI. Dacă ai nevoie să creezi un utilizator înainte de test, folosește cy.request() să faci un POST direct la API, nu să repeți un flow de înregistrare în fiecare spec. Testele rapide sunt teste care rulează și în pipeline, nu doar local.
Interceptare și mock — testezi comportamentul, nu backend‑ul
Aplicațiile React moderne consumă API‑uri. Uneori backend‑ul nu e disponibil în mediul de CI, alteori vrei să testezi cum reacționează UI‑ul la un răspuns de eroare 500. Cypress are cy.intercept() exact pentru asta:
cy.intercept('GET', '/api/products', { fixture: 'products.json' }).as('getProducts')
cy.visit('/shop')
cy.wait('@getProducts')
cy.get('[data‑cy="product‑list"]').should('have.length', 5)
Fișierul products.json stă în cypress/fixtures și conține datele pe care vrei să le controlezi. Testul nu depinde de baza de date, nu depinde de MySQL, nu depinde de disponibilitatea unui serviciu extern. Rulează consistent — local, în pipeline, în review app.
Această tehnică e deosebit de valoroasă în domenii precum banking sau retail, unde datele de test sunt sensibile sau greu de setat în medii de CI.
De la local la pipeline — ultimul pas care contează
Ai testele. Rulează verde pe mașina ta. Acum trebuie să convingi pipeline‑ul să le execute la fiecare Pull Request. Cypress vine cu un mod headless perfect pentru asta:
npx cypress run
Adaugi comanda în fișierul de configurare GitHub Actions, GitLab CI sau Jenkins, imediat după pasul de build. Un exemplu minimal pentru GitHub Actions:
- name: Run Cypress tests
run: npx cypress run
env:
CYPRESS_BASE_URL: http://localhost:3000
Dacă echipa ta folosește Cypress Cloud (fostul Cypress Dashboard), poți activa parallelization — testele se distribuie pe mai mulți runneri și suita completă se termină în fracțiune din timp. La un proiect cu 80‑100 de teste, diferența poate fi de la 12 minute la 3 minute. Contează când ai 15 PR‑uri pe zi.
Un lucru pe care îl auzi des la conferințe ca DevTalks sau A4Q Summit: calitatea unui pipeline se măsoară nu în câte teste ai, ci în câte dintre ele rulează stabil la fiecare commit. Un test flaky e mai rău decât niciun test — crează obișnuința de a ignora roșul.
Mindset‑ul care face diferența
Tool‑ul e Cypress. Framework‑ul e React. Dar ceea ce separă un tester bun de unul excepțional este felul în care gândește riscul înainte să scrie primul selector.
Ce e critic pentru utilizator? Ce poate merge prost în producție și afectează revenue sau reputația? Acolo pui energie, nu în a acoperi 100% din cod cu teste care nu testează nimic relevant.
Asta e gândirea risk‑based pe care o predăm la Academia Testarii — indiferent de tool, indiferent de stack.
Dacă vrei să mergi mai departe — să înveți cum structurezi o suită de test automation pentru un proiect real, cum integrezi Cypress cu JIRA pentru trasabilitate, cum prezinți rezultatele unui engineering lead sau unui CTO — cursurile noastre practice de la academiatestarii.ro sunt locul potrivit. Lucrăm cu scenarii din domenii reale: banking, retail, energie, automotive. Nu slideshow‑uri, nu teorie uscată — hands‑on, cu feedback real.
Intră pe academiatestarii.ro, uită-te la cursul de Test Automation și hai să scriem împreună următorul test verde. 🚀
#DeAziEstiTester #AcademiaTestarii #TestAutomation #Cypress #SoftwareTesting