Ho letto molte cose su TDD ma ho ancora dei dubbi. Ad esempio, ho questi diagrammi di classe:
È un semplice esempio, solo per conoscere TDD e gli oggetti mock.
Quale test dovrei scrivere per primo? Prodotto , quindi Linea e ultimo, Ordine ? Se lo faccio, dovrei utilizzare Linea e Prodotto per testare Ordine o dovrei usare Mock Objects? Quando dovrei usare Mock Objects? Dovrei usare UML con XP e TDD?
Non capisco ancora queste cose.
A giudicare dal diagramma, Product è una classe di dati stupidi, senza funzionalità da testare. Quindi inizierei a scrivere test per (e implementare, stile TDD) prima Linea e poi Ordine, su per la scala delle dipendenze. Di solito è ragionevole sottoporre a test le classi di livello inferiore prima di iniziare a lavorare su classi di livello superiore (cioè che dipendono dal livello inferiore). Questo rende gli errori di cattura più efficienti.
Se è necessario utilizzare oggetti fittizi dipende dalle dipendenze effettive della classe testata. Se si tratta di classi semplici che possono essere facilmente istanziate e configurate con i dati / stati desiderati per i test, non è necessario alcun mock. (Questo sembra essere il caso del tuo esempio qui.) Tuttavia, se una delle dipendenze è difficile da inizializzare / ha estese dipendenze stesse / ha effetti collaterali indesiderati / dipende da una risorsa esterna come un DB, allora ha senso utilizzare invece un oggetto fittizio.
Non vedo molto bisogno di oggetti finti qui. Come sottolineato da altri, hai bisogno di quelli soprattutto se le dipendenze sono difficili da configurare.
Ad esempio li abbiamo utilizzati con i progetti Ruby on Rails quando abbiamo testato i controller e avevamo bisogno di un accesso utente che avrebbe richiesto una chiamata a un altro controller e l'archiviazione di parte delle informazioni in un cookie. In questo caso è utile prendere in giro un utente che ha effettuato il login che restituisce true quando viene richiesto un determinato privilegio di accesso.
Normalmente per i test si vuole isolare il sistema / oggetto sotto test, in modo da prendere in giro tutto ciò che è al di fuori di questo. Quindi, usando il diagramma delle classi, durante il test di un oggetto ordine, usa una simulazione per l'oggetto linea. Durante il test della linea, utilizzare una simulazione per ordine e prodotto. Durante il test del prodotto, usa il mock per Line.
"TDD è principalmente una tecnica di progettazione con un effetto collaterale di garantire che il codice sorgente sia accuratamente testato unitamente" - Scott W. Ambler
L'idea è di trovare il design scrivendo i test unitari. Nel tuo caso, sembra che tu abbia già il design in atto, che blocca in qualche modo lo scopo di TDD (assumendo che il tuo design sia definitivo).
Per quanto riguarda il beffardo. Se vuoi prendere in giro, ti suggerisco di simulare il prodotto durante la scrittura dei test per Line e Mock Line durante il test di Order. Ma potrebbe essere eccessivo qui. Cerco personalmente di limitare il più possibile il mocking e di usarlo per disaccoppiare le dipendenze da classi esterne (come le istanze del database).
Leggi altre domande sui tag tdd unit-testing php mocking