"TDD riguarda la progettazione, non la verifica"; concretamente, cosa significa?

I kata del codice TDD riguardano le pratiche di apprendimento del TDD e il modo in cui guidano il design (e imparano un buon design in questo modo - sì, normalmente questo significa imparare come scrivere il codice SOLID)

Ciò significa che TDD sta per raggiungere un buon design, ma avere un codice ben progettato che non risolva un problema è inutile. È qui che entra in gioco la verifica, che può essere in molte forme, essendo il BDD uno di questi come una delle molte tecniche di collaudo automatico accettate.

La verifica consiste nell'assicurare che il codice scritto risolva il problema corretto.

Quindi, quando fai TDD, concentrati sulla progettazione - assicurati che sia pulita e SOLIDA.

Ma non dimenticare di aggiungere test unitari e test di accettazione (e qualsiasi altro test che si ritenga necessario).

Potrebbe essere utile vedere un'immagine:

Notacheitestdiaccettazione(cioèlaverifica)siedonoaldifuoridelsolitocicloTDD.L'unitàverificacheilcodicefunzioni,maitestdiaccettazioneassicuranocheilcodicesoddisfiirequisitidelcliente.

ATDDèl'acronimodi Sviluppo basato su test di accettazione

La verifica riguarda l'assicurazione che un prodotto soddisfi tutti i requisiti così come sono stati specificati. Test Driven Development , di per sé, non specifica la qualità dei test scritti e, come tale, non può garantire che un prodotto è completamente conforme alle sue specifiche. Quando scrivi i test per la prima volta, tendi a concentrarti sulla produzione di software che è facilmente verificabile: ottieni una quantità elevata di copertura del codice funzionale e hai l'opportunità di pensare a come dovrebbe apparire la tua API scrivendo il test prima di scrivere la funzionalità di backup.

Quando scrivi i tuoi test, dovresti anche pensare alla verifica - mappare i test alle tue esigenze, pensare ad altri percorsi di codice all'interno delle tue funzioni (ottenendo una dichiarazione più alta o una copertura decisionale). Ma TDD non dice nulla su questi - dice solo che dovresti scrivere prima i tuoi test e poi scrivere la quantità minima di codice per far passare i test. Senza garantire almeno la copertura completa dei requisiti dei test e una maggiore copertura del percorso, i test potrebbero non essere adatti a scopi di verifica.

> tdd is about design not verification.

Lo tradurrei in "il vantaggio di tdd è un buon design" .

In tdd ti concentri sulla scrittura del codice di verifica.

Facendo tdd (= scrivendo i test in isolamento prima di implementare il codice) si ottiene automaticamente un buon design (= accoppiamento minimo) come effetto collaterale.

Contro la scrittura di test automatici dopo l'implementazione del codice, si ottiene anche la verififcation, ma senza il vantaggio extra del design.

Si tratta di entrambi, ma la verifica è un buon effetto collaterale che potrebbe essere ottenuto scrivendo i test dopo il codice. Il vero vantaggio di TDD e la prima prova è che ti aiuta a migliorare il design perfezionando il design di ogni unità logica o regola aziendale e costruendo sul resto delle unità logiche senza rompere le altre unità del progetto e conservandole da diventare eccessivamente accoppiati.

Ad esempio alcuni sviluppatori usano l'approccio TDD quasi come una "lavagna bianca" dove i test e il codice vivono tutti nello stesso file inizialmente. Dà molta libertà di evolvere la logica con i test, oltre a testare le idee. Quindi, man mano che il design si evolve, il codice viene estratto dal modulo di test nell'applicazione stessa.

I test risultanti possono essere utilizzati per la verifica man mano che viene effettuato un ulteriore refactoring.