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 presunto per il consiglio sia qualcosa di simile:
- stai sviluppando un sistema per gli utenti, non, per esempio, una libreria di utilità o un framework.
- l'obiettivo del test è fornire con successo il più possibile entro un budget competitivo.
- i componenti sono scritti in un unico linguaggio maturo, probabilmente di tipo statico, come C # / Java.
- un componente è dell'ordine di 10000-50000 linee; un progetto Maven o VS, plugin 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 l' architettura esagonale
- una porta componente è dove si lascia la lingua locale, e il suo sistema di tipi, dietro, passando a http / SQL / XML / byte / ...
- il wrapping di ogni porta sono interfacce tipizzate, nel senso Java / C #, che possono avere implementazioni implementate per cambiare tecnologia.
Quindi testare un componente è l'ambito più ampio possibile in cui qualcosa può ancora essere ragionevolmente chiamato unit test. Questo è piuttosto diverso da come alcune persone, specialmente accademici, usano il termine. Non è niente come gli esempi nel tipico tutorial dello strumento di unit test. Tuttavia, corrisponde alla sua origine nei test hardware; schede e moduli sono testati dall'unità, non fili e viti. O almeno non costruisci un finto Boeing per provare una vite ...
Estrapolando da quello e gettando alcuni dei miei pensieri,
- Ogni interfaccia sarà un input, un output o un collaboratore (come un database).
- si prova le interfacce di input; chiama i metodi, asserisci i valori di ritorno.
- si deridere le interfacce di uscita; verificare che vengano chiamati i metodi previsti per un determinato caso di test.
- si finti i collaboratori; fornire un'implementazione semplice ma funzionante
Se lo fai in modo corretto e pulito, hai a malapena bisogno di uno strumento beffardo; viene utilizzato solo poche volte per sistema.
Un database è generalmente un collaboratore, quindi viene simulato piuttosto che deriso. Ciò sarebbe doloroso da attuare a mano; per fortuna cose del genere esistono già .
Lo schema di prova di base consiste nell'eseguire alcune sequenze di operazioni (ad es. Salvataggio e ricarica di un documento); confermare che funziona. Questo è lo stesso di qualsiasi altro scenario di test; nessun cambiamento di implementazione (funzionante) è suscettibile di causare il fallimento di tale test.
L'eccezione è dove i record del database vengono scritti ma mai letti dal sistema in prova; ad es. registri di controllo o simili. Questi sono output e quindi dovrebbero essere derisi. Lo schema di test prevede alcune sequenze di operazioni; confermare che l'interfaccia di controllo è stata chiamata con metodi e argomenti come specificato.
Si noti che anche qui, a condizione che si stia utilizzando uno strumento di simulazione di tipo sicuro come mockito , la ridenominazione di un metodo di interfaccia non può causare un errore del test. Se si utilizza un IDE con i test caricati, verrà refactored insieme al metodo rinomina. In caso contrario, il test non verrà compilato.