⚡Claude Code v2.1
Modulul 09 · 20 min

Workflow TDD

Test-Driven Development cu agentul AI — scrie teste INAINTE de cod, fara exceptii.

De ce TDD cu un agent AI?

Poate parea contraintuitiv: de ce ar folosi un agent AI (care poate genera cod instant) o metodologie lenta ca TDD? Raspunsul: pentru ca AI face greseli.

  • AI genereaza cod care arata corect dar are bug-uri subtile
  • Testele scrise inainte definesc clar ce inseamna "corect"
  • Fara teste, nu ai cum sa verifici ca fix-urile nu sparg altceva

💡 Dovada din Phase 001

In acest proiect, TDD a prins 2 bug-uri reale in scriptul de validare: un gotcha bash cu ((var++)) si o problema cu set -ein command substitution. Fara teste, aceste bug-uri ar fi trecut neobservate.

Ciclul TDD: Red → Green → Refactor

RED
Scrie test care ESUEAZA
→
GREEN
Cod minimal sa treaca
→
REFACTOR
Curata fara schimb comportament

Faza RED — Scrie testul

Scrii un test care defineste comportamentul dorit. Testul trebuie sa esueze.

# Exemplu real din Phase 001:

# Test: scriptul validate-structure.sh exista si ruleaza
test_script_exists() {
  assert_file_exists "validate-structure.sh"
}

# Test: scriptul raporteaza toate componentele
test_reports_all_components() {
  OUTPUT="$(bash validate-structure.sh)"
  assert_contains "$OUTPUT" "33 passed"
}

🚫 Testul care trece la prima

Daca un test trece imediat dupa ce l-ai scris (fara sa scrii codul), testul e probabil gresit. Verifica ca testul chiar prinde esecuri reale. Un test care trece mereu e inutil.

Faza GREEN — Cod minimal

Scrii cel mai putin cod posibil care face testul sa treaca. Nu optimizezi, nu refactorizezi, nu adaugi features — doar faci testul verde.

Faza REFACTOR — Curata

Acum ca ai teste verzi, poti restructura codul cu incredere. Testele garanteaza ca nu ai spart nimic.

Regulile TDD in sistemul v2.1

  1. Scrii teste INAINTE de cod. Intotdeauna. Fara exceptii.
  2. Confirmi ca testul esueaza inainte de a scrie codul
  3. Scrii cod minimal — doar ce trebuie sa treaca testul
  4. Confirmi ca testul trece dupa implementare
  5. Dupa 3 incercari esuate de fix → stop → revizuire arhitecturala
  6. Fiecare test + cod = un atomic commit

Exemplu complet din Phase 001

Iata fluxul real al TDD din prima faza a acestui proiect:

1. RED — Test scris

Testul ruleaza validate-structure.sh si asteapta exit code 0. Rezultat: FAIL — scriptul nu exista inca.

2. GREEN — Cod scris

Script creat cu 33 verificari. Ruleaza testul: FAIL — bug! ((PASS++)) returneaza exit 1 cand PASS=0 (gotcha bash).

3. FIX — Bug gasit de test

Inlocuit ((PASS++)) cu PASS=$((PASS + 1)). Ruleaza testul: FAIL — alt bug! set -e + command substitution.

4. FIX — Al doilea bug gasit

Eliminat set -e din test runner. Ruleaza testul: PASS — toate 7 asertiunile trec.

5. COMMIT — Atomic commit

feat: add structure validation script with TDD tests

ℹ️ 2 bug-uri gasite

TDD a gasit 2 bug-uri pe care o simpla inspectie vizuala a codului nu le-ar fi prins. Acesta e motivul pentru care agentul scrie teste inainte de cod.

Exercitiu

Deschide tests/test_validate_structure.sh si validate-structure.sh. Identifica cele 7 asertiuni din test. Apoi citeste SUMMARY.md din Phase 001 si compara cu ce ai vazut in cod — lectiile invatate corespund bug-urilor din cod?

Verifica-ti cunostintele

Ce faci daca un test trece la prima scriere (fara sa fi scris codul)?