Ghid Operator: Dezvoltare Ghidată de Teste (TDD)

Salut! Ești aici pentru că vrei să scrii cod mai bun, mai robust și mai ușor de întreținut. Excelent! Abilitatea test-driven-development (TDD) este exact ce-ți trebuie. Nu e doar o tehnică, e o mentalitate care-ți va schimba modul în care construiești software.

Ce face

Pe scurt, TDD îți impune să scrii testul înainte de a scrie codul de implementare. Sună contraintuitiv? Poate, dar e super eficient. Ciclul e simplu:

  1. Scrii un test care eșuează (pentru că funcționalitatea nu există încă).
  2. Vezi testul eșuând (asta e crucial!).
  3. Scrii cel mai puțin cod necesar pentru ca testul să treacă.
  4. Refactorizezi codul, asigurându-te că testele rămân verzi.

Principiul de bază este de fier: Dacă nu ai văzut testul eșuând, nu știi dacă testează lucrul corect. A sări peste această etapă înseamnă a încălca spiritul regulilor, nu doar litera lor.

Când îmi folosește

Întotdeauna ar trebui să folosești TDD pentru:

  • Funcționalități noi: Orice bucată de comportament nou.
  • Corectarea bug-urilor: Scrie un test care reproduce bug-ul, vezi-l eșuând, apoi scrie codul care-l repară.
  • Refactorizare: Ai un test care acoperă codul vechi? Excelent! Refactorizează și asigură-te că testul rămâne verde. Dacă nu ai, scrie-l!
  • Modificări de comportament: Orice schimbare în modul în care funcționează aplicația.

Excepții (discută cu partenerul tău uman):

  • Prototipuri “throwaway” (care nu ajung în producție).
  • Cod generat automat.
  • Fișiere de configurare simple.

Dacă te gândești “să sar peste TDD doar de data asta”, oprește-te. E o raționalizare. De cele mai multe ori, vei pierde mai mult timp pe termen lung.

Cum îl invoc / declanșez

TDD nu este o comandă pe care o tastezi, ci o abilitate și o disciplină pe care o aplici la fiecare sarcină de dezvoltare. O “invoci” prin decizia de a urma ciclul Red-Green-Refactor.

Practic, începi o sarcină (feature, bugfix) și, în loc să scrii direct codul de implementare, deschizi fișierul de teste corespunzător (sau creezi unul nou) și scrii primul test.

Pașii cheie în “invocarea” TDD sunt:

  1. Decide ce comportament specific vrei să implementezi sau să corectezi.
  2. Scrie un test pentru acel comportament.
  3. Rulează testul (de exemplu, npm test path/to/test.test.ts) și verifică că eșuează corect.
  4. Scrie codul de implementare.
  5. Rulează testele și verifică că toate trec.
  6. Refactorizează și repetă.

Exemplu practic

Ciclul TDD se numește Red-Green-Refactor:

RED - Scrie testul care eșuează

Scrie un test minimal care demonstrează un singur comportament dorit și care, evident, va eșua pentru că funcționalitatea nu există.

```typescript test('retries failed operations 3 times', async () => { let attempts =