Ho letto molte cose su TDD ma ho ancora dubbi. Ad esempio, ho questi diagrammi di classe:
È un semplice esempio, solo per conoscere TDD e oggetti finti.
Quale test dovrei scrivere per primo? Prodotto , quindi Linea e ultimo, Ordine ? Se lo faccio, dovrei usare Line e Product per testare Order o dovrei usare Mock Objects? Quando dovrei usare Mock Objects? Dovrei usare UML con XP e TDD?
Non ho ancora queste cose.
Risposte:
A giudicare dal diagramma, il prodotto è una classe di dati stupida, senza funzionalità da testare. Quindi inizierei a scrivere test per (e implementare, in stile TDD) prima Linea e poi Ordine, nella scala delle dipendenze. Di solito è sensato sottoporre a test le tue classi di livello inferiore prima di iniziare a lavorare su classi di livello superiore (cioè che dipendono dal livello inferiore). Ciò rende più efficace la cattura dei bug.
La necessità di utilizzare oggetti simulati dipende dalle dipendenze effettive della classe testata. Se si tratta di classi semplici che puoi facilmente istanziare e configurare con qualsiasi dato / stato desiderato richiesto per i tuoi test, non hai bisogno di beffe. (Questo sembra essere il caso del tuo esempio di progettazione qui.) Tuttavia, se una delle dipendenze è difficile da inizializzare / ha dipendenze estese in sé / ha effetti collaterali indesiderati / dipende da una risorsa esterna come un DB, allora ha senso per usare invece un oggetto finto.
Non vedo molto bisogno di oggetti finti qui. Come sottolineato da altri, sono necessari soprattutto se le dipendenze sono difficili da configurare.
Ad esempio, li abbiamo usati con i progetti Ruby on Rails quando abbiamo testato i controller e avevamo bisogno di un login utente che avrebbe richiesto una chiamata a un altro controller e la memorizzazione di parte delle sue informazioni in un cookie. In questo caso è utile deridere un utente che ha restituito true, quando gli viene chiesto un determinato privilegio di accesso.
Normalmente per i test si desidera isolare il sistema / oggetto in prova, quindi si deriderebbe tutto ciò che non lo è. Quindi, usando il tuo diagramma di classe, quando collaudi un oggetto ordine, usa un finto per l'oggetto linea. Durante il test della linea, utilizzare un finto per ordine e prodotto. Durante il test del prodotto, utilizzare il finto per Line.
"TDD è principalmente una tecnica di progettazione con un effetto collaterale di garantire che il codice sorgente sia accuratamente testato dall'unità" - Scott W. Ambler
L'idea è quella di trovare il design scrivendo unit test. Nel tuo caso, sembra che tu abbia già il design in atto, che in qualche modo sconfigge lo scopo di TDD (supponendo che il tuo design sia definitivo).
Per quanto riguarda il beffardo. Se vuoi deridere, ti suggerisco di deridere il Prodotto quando scrivi i test per Line e simula la Linea quando collaudi Order. Ma potrebbe essere eccessivo qui. Personalmente cerco di limitare il beffardo il più possibile e lo uso per disaccoppiare le dipendenze da classi esterne (come le istanze di database).