De ce și ce testăm
Test automat, Arrange-Act-Assert, tipuri de teste și ce merită testat.
Actualizat
Ce este un test automat
Un test automat e cod care rulează alt cod și verifică că face ce trebuie. În loc să deschizi browserul și să dai click de mână după fiecare modificare, rulezi o comandă și afli în câteva secunde dacă ai stricat ceva.
test('aplică reducerea de 10%', () => {
expect(applyDiscount(100, 'WELCOME10')).toBe(90)
})Exact ce fac exercițiile din aplicația asta: codul tău + câteva verificări.
De ce merită
- Încredere la schimbări — refactorizezi fără frică; testele îți spun dacă ai stricat ceva.
- Bug-uri prinse devreme — în CI, nu de useri.
- Documentație — testele arată cum se folosește codul.
- Design mai bun — codul greu de testat e de obicei prea cuplat.
Anatomia unui test: Arrange – Act – Assert
test('adaugă produsul în coș', () => {
const cart = createCart() // Arrange — pregătești datele
cart.add({ id: 1, price: 50 }) // Act — rulezi codul testat
expect(cart.total).toBe(50) // Assert — verifici rezultatul
})Tipuri de teste
| Tip | Testează | Viteză | Încredere | Unelte |
|---|---|---|---|---|
| static | tipuri, greșeli de sintaxă, stil | instant | de bază | TypeScript, ESLint |
| unit | o funcție / un modul, izolat | ms | pentru logică | Vitest |
| integration | mai multe piese împreună (componentă + hook + date) | rapid | mare | Vitest + Testing Library |
| end-to-end (E2E) | aplicația reală, într-un browser real, ca un user | secunde | maximă | Playwright |
Piramida vs „trofeul”
Clasic: piramida — multe teste unit, mai puține de integrare, puține E2E.
Pentru frontend, recomandarea modernă (Kent C. Dodds) e „testing trophy”: baza statică (TS + ESLint), cele mai multe teste de integrare, câteva unit pentru logica complicată și câteva E2E pentru fluxurile critice (login, checkout).
Motivul: un test de integrare seamănă mai mult cu felul în care userul folosește aplicația → îți dă mai multă încredere per test scris.
Ce merită testat
| Prioritate mare | Prioritate mică |
|---|---|
| logică de business (prețuri, reduceri, validări) | detalii de stil, culori |
| fluxuri critice (login, plată, salvare) | cod de framework (Next își testează singur routing-ul) |
| bug-uri reparate (un test ca să nu revină) | getteri / setteri triviali |
| funcții utilitare folosite peste tot | implementare internă care se schimbă des |
Testează comportamentul, nu implementarea. Un test bun nu se strică când redenumești o variabilă internă — doar când comportamentul vizibil se schimbă.
Pe scurt
- Test = cod care verifică alt cod; Arrange → Act → Assert.
- Static, unit, integration, E2E — fiecare cu cost și încredere diferite.
- Testează comportamentul, prioritizează logica de business și fluxurile critice.