Quali sono le scuole di TDD a Londra e Chicago?

Supponiamo di avere una classe chiamata "ledger" un metodo chiamato "calcola" che utilizza un "Calcolatrice" per eseguire diversi tipi di calcoli a seconda degli argomenti passati a "calcolare", ad esempio "moltiplicare (x, y)" o "sottrazione (x, y)".

Ora, supponiamo di voler testare cosa succede quando chiami ledger.calculate ("5 * 7").

La scuola London / Interaction ti chiederà se è stato chiamato Calculator.multiply (5,7). I vari framework di simulazione sono utili per questo e possono essere molto utili se, ad esempio, non si ha la proprietà dell'oggetto "Calcolatrice" (supponiamo che si tratti di un componente o servizio esterno che non è possibile testare direttamente, ma lo si fa sai che devi chiamare in un modo particolare).

La scuola di Chicago / State dovrebbe farti valere se il risultato è 35. I framework jUnit / nUnit sono generalmente orientati a farlo.

Entrambi sono test validi e importanti.

L'articolo Mazzi non sono stub , di Martin Fowler è una buona introduzione all'argomento.

A seconda dello stile di progettazione scelto (e dei principi di progettazione su cui si creano i programmi), ci sono almeno due modi di vedere un oggetto:

1. Come unità che esegue calcoli basati su input. Come risultato di questo calcolo, l'oggetto può restituire un valore o modificarne lo stato.
2. Come elemento attivo che comunica con altri elementi nel sistema tramite il messaggio che passa.

Nel primo caso, sei interessato a ciò che viene fuori dall'elaborazione o in quale stato l'oggetto viene lasciato dopo quell'elaborazione. È qui che metodi come assertEquals() inseriscono l'immagine. In questo caso, non importa molto quali altri oggetti sono stati coinvolti nell'elaborazione, quali sono stati chiamati i metodi, ecc. Questo tipo di verifica si chiama verifica basata sullo stato ed è lo stile "classico".

Nel secondo caso, dal momento che la maggior parte degli oggetti non restituisce alcun risultato (es. void metodi in Java), sei più interessato a come gli oggetti comunicano tra loro e se passano i messaggi giusti nelle circostanze imposte dal test. Queste interazioni sono solitamente verificate con l'ausilio di strutture simulate. Questo tipo di verifica si chiama verifica basata sul comportamento o sull'interazione. Una delle sue implicazioni è la tecnica chiamata Behavior Driven Development, con cui sviluppi una classe assumendo che i suoi collaboratori esistano già (anche se potrebbero non esistere ancora), quindi puoi codificare le loro interfacce.

Si noti che questa non è una scelta / o. Puoi avere uno stile di design che combina entrambi gli approcci per ottenere il meglio da ciascuno di essi.