La mia interpretazione di quel discorso è:
- componenti di test, non classi.
- testare i componenti attraverso le loro porte di interfaccia.
Non è indicato nel discorso, ma penso che il contesto ipotizzato per il consiglio sia qualcosa del tipo:
- stai sviluppando un sistema per gli utenti, non, per esempio, una libreria di utilità o un framework.
- l'obiettivo del test è riuscire a fornire il più possibile in un budget competitivo.
I componenti - sono scritti in un unico, maturo, probabilmente tipizzato staticamente, linguaggio come C # / Java.
- un componente è dell'ordine di 10000-50000 linee; un progetto Maven o VS, un plug-in OSGI, ecc.
I componenti - sono scritti da un singolo sviluppatore o da un team strettamente integrato.
- stai seguendo la terminologia e l'approccio di qualcosa come architettura esagonale
- una porta del componente è quella in cui si lascia la lingua locale, e il suo tipo di sistema, dietro, passando a http / SQL / XML / byte /...
- il wrapping di ogni porta sono interfacce tipizzate, in senso Java / C #, che possono avere implementazioni disattivate per cambiare tecnologia.
Quindi testare un componente è il più ampio ambito possibile in cui qualcosa possa ancora essere ragionevolmente definito test unitario. Questo è piuttosto diverso da come alcune persone, specialmente gli accademici, usano il termine. Non è niente come gli esempi nel tipico tutorial sugli strumenti di test unitario. Tuttavia, corrisponde alla sua origine nei test dell'hardware; schede e moduli sono testati unitamente, non cavi e viti. O almeno non costruisci un finto Boeing per testare una vite ...
Estrapolando da ciò e inserendo alcuni dei miei pensieri,
- Ogni interfaccia sarà o un input, un output o un collaboratore (come un database).
- tu prova le interfacce di input; chiama i metodi, asserisci i valori di ritorno.
- tu mock le interfacce di output; verificare che i metodi previsti siano chiamati per un dato test case.
- tu falso i collaboratori; fornire un'implementazione semplice ma funzionante
Se lo fai correttamente e in modo pulito, hai a malapena bisogno di uno strumento di derisione; viene utilizzato solo poche volte per sistema.
Un database è generalmente un collaboratore, quindi diventa falso piuttosto che deriso. Ciò sarebbe doloroso da implementare a mano; fortunatamente queste cose esistono già .
Il modello di test di base è una sequenza di operazioni (ad esempio salvataggio e ricarica di un documento); conferma che funziona. Questo è uguale a qualsiasi altro scenario di test; nessuna modifica di implementazione (di lavoro) può causare il fallimento di tale test.
L'eccezione è dove i record del database sono scritti ma mai letti dal sistema sotto test; per esempio. registri di audit o simili. Queste sono uscite, e quindi dovrebbero essere prese in giro. Il modello di prova è una sequenza di operazioni; conferma che l'interfaccia di controllo è stata chiamata con metodi e argomenti come specificato.
Nota che anche qui, purché tu stia utilizzando uno strumento di simulazione di tipo sicuro come mockito , non è possibile rinominare un metodo di interfaccia causa un fallimento del test. Se si utilizza un IDE con i test caricati, verrà refactored insieme al metodo rinominare. Se non lo fai, il test non verrà compilato.