Come praticare l'ATDD se il design non è ancora emerso da TDD?

I test di accettazione accedono all'applicazione tramite un'API per scopi speciali.

Hai presentato questo caso d'uso:

Dato che Michael è appena stato creato nell'applicazione, il suo stato dovrebbe essere lasciato a non attivato.

L'API implicita da questo caso d'uso è simile a:

CreateUser(String name);
enum UserStatus {non-activated};
UserStatus GetUserStatus(String name);

Finora questo non ha nulla a che fare con TDD. È solo una semplice API che i tuoi test di accettazione possono utilizzare per accedere all'applicazione.

Ora, per superare questo test di accettazione, dovrai implementare questa API. Questo è quando inizi a fare TDD. Le decisioni che prendi mentre provi a guidare la soluzione ti aiuteranno a determinare il design dell'applicazione.

Si noti che il design dell'applicazione non ha nulla a che fare con il design dell'API utilizzato dai test di accettazione. Quella API è uno strato adattatore tra questi test e la tua applicazione. Questo livello consente alla tua applicazione di assumere qualsiasi disegno tu desideri.

Riguardo a TDD e design. È vero che il design emerge da TDD. Ma TDD non è l'unico processo con cui progetta la tua applicazione. Pensi anche attraverso il design in molti altri modi. È possibile disegnare alcuni diagrammi UML. Potresti usare le carte CRC. Potresti avere una sessione di progettazione con i tuoi colleghi di lavoro. In effetti, dovresti fare TUTTE queste cose.

E dovresti anche consentire ai disegni di emergere con TDD. TDD non sostituisce gli strumenti di progettazione precedenti, aggiunge un nuovo strumento al kit.

Alcune persone si lamenteranno probabilmente che questo suona come BDUF, e non suona molto "Agile". Il problema è la lettera "B". È del tutto vero che non vogliamo fare grandi progetti in anticipo. Ma non è affatto vero che non vogliamo fare qualche disegno in anticipo. Noi facciamo! Poche ore o addirittura giorni di progettazione in anticipo non sono male. Mesi e mesi.

...shouldn't it be the role of TDD to emerge the design and therefore these components?

No.

Questo è un malinteso comune su TDD. Lo scopo di TDD non è quello di "far crescere un design". Lo scopo di TDD è di assicurare che un programma rimanga "ben progettato". TDD ti costringerà a creare un'API testabile e da essa emergeranno requisiti funzionali specifici. Ma non creerà il tuo design per te. Devi farlo da solo.

ATDDtiaiuteràaprogettareiltuoprogrammafornendorequisiticoncretieverificabiliaiclienti.Èunapproccioeminentementepratico:affermandoinanticipoirequisitideltestdiaccettazione,ilclientetihadettoesattamentecosadevefareiltuoprogrammaperdichiarareilsuccesso.

Vedianche
Jim Coplien e Bob Martin Dibattito TDD
ritorno dello zio Bob (pagina 3)

In pratica, tendo a lasciare un po 'ruvido il design quando partiamo per la prima volta con un test di accettazione, introducendo semplicemente versioni semplicistiche di concetti per fare progressi. Il trucco è riconoscere quando si hanno sufficienti informazioni sul progetto implicito per il refactoring.

In realtà, penso che tu abbia un problema più grande con il tuo primo test. Stai iniziando con il primo passo della sequenza, non la caratteristica più importante / interessante del sistema. A Michael non interessa il processo di creazione degli utenti, quindi puoi iniziare con gli utenti codificati e prenderli da lì.

Thus my question would be...how to write it? since I don't even already know what is a "User", what is a status etc... Indeed, shouldn't it be the role of TDD to emerge the design and therefore these components?

Non sei sicuro di cosa intendi per "non so che cos'è un utente", ma direi che questo tipo di concetti di grande impresa non emergono dal nulla nel codice come risultato del processo TDD, essi dovrebbe essere conosciuto in anticipo, almeno a grandi linee.

Gli approcci come Domain Driven Design raccomandano di avere sessioni preliminari di modellazione collaborativa in cui esperti di domini e sviluppatori siedono insieme, esplorando concetti di dominio e iniziando a coltivare un linguaggio ubiquo.

I primi schizzi del modello di dominio risultante da queste conversazioni dovrebbero fornire un piano di base per iniziare con i test di accettazione. Esprimere i test ATDD dovrebbe essere più semplice e naturale poiché continui ad usare lo stesso linguaggio ubiquo di prima per scrivere concetti di dominio di grandi dimensioni nel codice.