Cos'è un finto e quando dovresti usarlo?

Question

Ho appena letto l'articolo di Wikipedia su oggetti finti , ma non sono ancora del tutto chiaro sul loro scopo. Sembra che siano oggetti creati da un framework di test quando l'oggetto reale sarebbe troppo complesso o imprevedibile (sai al 100% sicuro quali sono i valori dell'oggetto finto perché li controlli completamente).

Tuttavia, avevo l'impressione che tutti i test vengano eseguiti con oggetti con valori noti, quindi mi manca qualcosa. Ad esempio, in un progetto di corso, ci è stato assegnato un compito con un'applicazione di calendario. La nostra suite di test consisteva in oggetti evento che sapevamo esattamente cosa fossero in modo da poter testare le interazioni tra più oggetti evento, vari sottosistemi e l'interfaccia utente. Immagino che questi siano oggetti finti, ma non so perché non lo faresti perché senza gli oggetti con valori noti, non puoi testare un sistema.

Answer 1

Un oggetto simulato non è solo un oggetto con valori noti. È un oggetto che ha la stessa interfaccia di un oggetto complesso che non è possibile utilizzare nel test (come una connessione al database e set di risultati), ma con un'implementazione che è possibile controllare nel test.

Ci sono framework beffardi che ti permettono di creare questi oggetti al volo e, in sostanza, ti permettono di dire qualcosa del tipo: Fammi un oggetto con un metodo foo che prende un int e restituisce un valore. Quando passo 0, dovrebbe tornare vero. Quindi puoi testare il codice che utilizza foo (), per assicurarti che reagisca in modo appropriato.

Martin Fowler ha un ottimo articolo sul deridere:

• http://martinfowler.com/articles/mocksArentStubs.html

Answer 2

Pensa al classico caso di avere software client e server. Per testare il client, è necessario il server; per testare il server, è necessario il client. Ciò rende praticamente impossibile il collaudo delle unità, senza usare simulazioni. Se deridi il server, puoi testare il client in isolamento e viceversa.

Il punto della derisione non è duplicare il comportamento delle cose che sta deridendo però. È più una semplice macchina a stati i cui cambiamenti di stato possono essere analizzati dal framework di test. Quindi un client mock potrebbe generare dati di test, inviarli al server e quindi analizzare la risposta. Ti aspetti una certa risposta a una richiesta specifica e quindi puoi verificare se la ricevi.

Answer 3

Sono d'accordo con tutto @Lou Franco dice e dovresti assolutamente leggere l'eccellente articolo di Martin Fowler sui test che raddoppia a cui @Lou Franco ti punta.

Lo scopo principale di qualsiasi test double (fake, stub o mock) è di isolare l'oggetto in test in modo che il test unitario stia testando solo quell'oggetto (non le sue dipendenze e gli altri tipi con cui collabora o interagisce).

Un oggetto che fornisce l'interfaccia da cui dipende l'oggetto può essere usato al posto della dipendenza effettiva in modo che possano essere poste le aspettative che si verifichino determinate interazioni. Questo può essere utile, ma ci sono alcune controversie sui test basati sullo stato contro quelli basati sull'interazione. L'uso eccessivo delle aspettative finte porterà a test fragili.

Un ulteriore motivo per raddoppiare i test è rimuovere le dipendenze da database o file system o altri tipi che sono costosi da configurare o eseguire operazioni che richiedono tempo. Ciò significa che puoi ridurre al minimo il tempo necessario per testare l'unità dell'oggetto a cui sei interessato.

Answer 4

Ecco un esempio: se stai scrivendo codice che popola un database, potresti voler verificare se un particolare metodo ha aggiunto dati al database.

L'impostazione di una copia del database per il test ha il problema che se si assume che non ci siano record prima della chiamata al metodo testato e un record dopo, è necessario ripristinare il database a uno stato precedente, aggiungendo quindi al sovraccarico per l'esecuzione del test.

Se si presume che ci sia un solo record in più rispetto a prima, potrebbe scontrarsi con un secondo tester (o anche un secondo test nello stesso codice) che si collega allo stesso database, causando così dipendenze e rendendo fragili i test.

La simulazione ti consente di mantenere i test indipendenti l'uno dall'altro e facili da configurare.

Questo è solo un esempio: sono sicuro che altri possano fornirne di più.

Sono d'accordo al 100% con gli altri collaboratori su questo argomento, in particolare con la raccomandazione per l'articolo di Martin Fowler.

Answer 5

Potresti essere interessato al nostro libro, vedi http: //www.growing-object -oriented-software.com/. È in Java, ma le idee si applicano ancora.