Nel mondo dello sviluppo software, le metodologie "Driven" promettono tutte la stessa cosa: codice migliore, meno bug, team allineati. Ma TDD, BDD e SDD sono approcci diversi con filosofie diverse.
Ho usato tutti e tre in progetti reali. Ecco cosa ho imparato su quando brillano e quando sono overkill.
TDD: Test-Driven Development
L'idea
Scrivi il test prima del codice. Il ciclo è:
- Red: scrivi un test che fallisce
- Green: scrivi il minimo codice per farlo passare
- Refactor: migliora il codice mantenendo i test verdi
Esempio
Devo implementare una funzione che calcola lo sconto:
// 1. RED - scrivo il test
test('applica 10% sconto per ordini sopra 100€', () => {
expect(calculateDiscount(150)).toBe(15);
});
// 2. GREEN - implemento il minimo
function calculateDiscount(amount: number): number {
if (amount > 100) return amount * 0.1;
return 0;
}
// 3. REFACTOR - miglioro se serve
Pro
- Forza a pensare ai casi d'uso prima di scrivere codice
- Copertura test garantita (se segui il processo)
- Design emergente: il codice si modella sui test
- Feedback loop velocissimo
Contro
- Curva di apprendimento ripida
- Può rallentare su codice esplorativo
- I test possono diventare fragili se troppo legati all'implementazione
- Non cattura il "perché" di business
Quando usarlo
TDD funziona bene per:
- Logica di dominio complessa
- Librerie e utility functions
- Bug fix (scrivi test che riproduce, poi fixa)
BDD: Behavior-Driven Development
L'idea
Descrivi il comportamento del sistema in linguaggio naturale, comprensibile anche da non-tecnici. Il formato classico è Gherkin:
Feature: Sconto ordini
Scenario: Ordine sopra soglia minima
Given un carrello con totale 150€
When l'utente procede al checkout
Then lo sconto applicato è 15€
Strumenti tipici
- Cucumber (JS, Ruby, Java)
- Behave (Python)
- SpecFlow (.NET)
Pro
- Linguaggio condiviso tra dev, QA e business
- Documentazione vivente (gli scenari sono sempre aggiornati)
- Facilita la collaborazione cross-funzionale
- Gli scenari sono leggibili da chiunque
Contro
- Overhead di traduzione Gherkin → codice
- Può diventare verboso per logica complessa
- Richiede disciplina per mantenere scenari puliti
- Il business raramente scrive scenari (nella pratica li scrive il dev)
Quando usarlo
BDD funziona bene per:
- Team con forte componente non-tecnica
- Feature user-facing con molti scenari
- Progetti dove i requisiti cambiano spesso
SDD: Spec-Driven Development
L'idea
Scrivi una specifica completa prima di toccare codice. La specifica include:
- Obiettivi di business
- Comportamenti attesi
- Vincoli tecnici
- Criteri di accettazione
- Non-goal
Da questa specifica derivano test, implementazione e documentazione.
Esempio
# Feature: Sconto Ordini
## Obiettivo
Incentivare ordini di valore maggiore applicando sconti progressivi.
## Comportamenti
- Ordini < 100€: nessuno sconto
- Ordini 100-200€: 10% sconto
- Ordini > 200€: 15% sconto
## Vincoli
- Lo sconto si applica sul totale pre-tasse
- Arrotondamento a 2 decimali
## Criteri di accettazione
- [ ] Ordine 50€ → sconto 0€
- [ ] Ordine 150€ → sconto 15€
- [ ] Ordine 250€ → sconto 37.50€
## Non-goal
- Sconti cumulabili con coupon (fase 2)
Pro
- Visione completa prima di iniziare
- Perfetto per AI-assisted development
- Cattura il "perché", non solo il "cosa"
- Riduce ambiguità e rework
Contro
- Overhead iniziale significativo
- Richiede disciplina per mantenere spec aggiornate
- Overkill per task semplici
- Può creare false certezze (la spec non è il software)
Quando usarlo
SDD funziona bene per:
- Workflow con agenti AI (la spec è l'input)
- Feature complesse multi-stakeholder
- Progetti dove la documentazione conta
- Quando vuoi prevedere prima di costruire
Confronto diretto
| Aspetto | TDD | BDD | SDD | |---------|-----|-----|-----| | Focus | Correttezza del codice | Comportamento utente | Intento completo | | Artefatto | Test unitari | Scenari Gherkin | Documento specifica | | Chi scrive | Developer | Dev + QA (idealmente business) | Team cross-funzionale | | Granularità | Funzione/metodo | Scenario utente | Feature intera | | AI-friendly | Medio | Medio | Alto | | Overhead | Basso | Medio | Alto | | Curva apprendimento | Media | Media | Bassa |
Come combinarli
Non sono mutualmente esclusivi. Nella pratica uso:
SDD + TDD
- Scrivo la specifica (SDD)
- Derivo i criteri di accettazione come test (TDD)
- Implemento seguendo red-green-refactor
La specifica dà direzione, TDD dà feedback veloce.
BDD per feature user-facing + TDD per logica interna
- BDD: "L'utente può prenotare uno slot disponibile"
- TDD: Test unitari per
calculateAvailableSlots()
BDD cattura l'esperienza utente, TDD verifica i dettagli implementativi.
SDD come pre-requisito
Prima di iniziare qualsiasi feature non triviale, scrivo una spec. Poi decido se usare TDD, BDD o entrambi per l'implementazione.
Quale scegliere?
La risposta onesta: dipende.
| Situazione | Approccio consigliato | |------------|----------------------| | Bug fix isolato | TDD | | Utility function | TDD | | Feature user-facing semplice | BDD | | Feature complessa con AI | SDD → TDD | | Progetto con molti stakeholder | SDD + BDD | | Spike esplorativo | Nessuno (prima capisci, poi struttura) | | Prototipo veloce | Nessuno |
La cosa peggiore è applicare metodologie pesanti a task leggeri, o nessuna metodologia a task complessi.
Il mio approccio
Personalmente:
- Sempre penso ai criteri di accettazione prima di scrivere codice (mentalità SDD)
- Spesso uso TDD per logica di dominio e funzioni pure
- A volte uso BDD per feature con molti scenari utente
- Mai applico metodologie rigide a task banali
L'obiettivo non è seguire una metodologia. È scrivere software che funziona e che altri possono capire.
Conclusione
TDD, BDD e SDD sono strumenti, non religioni. Ognuno risolve problemi diversi:
- TDD: "Il mio codice fa quello che penso?"
- BDD: "Il sistema si comporta come l'utente si aspetta?"
- SDD: "Stiamo costruendo la cosa giusta?"
La vera skill è sapere quando usare quale. E con l'AI che entra sempre più nel loop di sviluppo, SDD sta diventando sempre più rilevante — perché una specifica chiara è il miglior prompt che puoi dare a un agente.
Vuoi approfondire?
Se vuoi capire quale approccio funziona meglio per il tuo team o progetto, posso aiutarti a valutare e implementare la metodologia giusta.
Contattami per una consulenza su processi di sviluppo e best practice.