Cos’è l’Object Mocking e quando ne ho bisogno?

Molte persone usano oggetti Mock mentre scrivono i test unitari. Cos’è un object Mock ? Perché mai avrei bisogno di uno? Ho bisogno di un Mock Object Framework?

L’Object Mocking viene utilizzato per mantenere le dipendenze fuori dal test dell’unità. A volte avrai un test come “SelectPerson” che selezionerà una persona dal database e restituirà un object Person.

Per fare questo, normalmente dovresti avere una dipendenza dal database, tuttavia con l’object mocking puoi simulare l’interazione con il database con un framework mock, quindi potrebbe restituire un set di dati che sembra uno restituito dal database e puoi quindi testare il codice per garantire che gestisca la traduzione di un set di dati su un object persona, piuttosto che utilizzarlo per verificare che esista una connessione al database.

Diverse persone hanno già risposto al “cosa”, ma qui ci sono un paio di rapidi “perché” che mi viene in mente:

  1. Prestazione

    Poiché i test unitari devono essere rapidi, testare un componente che interagisce con una rete, un database o altra risorsa che richiede un notevole dispendio di tempo non deve pagare la penalità se viene eseguita utilizzando oggetti fittizi. I risparmi si sumno rapidamente.

  2. Collaborazione

    Se stai scrivendo un pezzo di codice ben incapsulato che deve interagire con il codice di qualcun altro (che non è stato ancora scritto, o è in fase di sviluppo in parallelo – uno scenario comune), puoi esercitare il tuo codice con oggetti finti una volta l’interfaccia è stata concordata. In caso contrario, il tuo codice potrebbe non essere testato fino a quando l’altro componente non sarà terminato.

Un object mock ti permette di testare solo ciò che stai scrivendo, e dettagli astratti come l’accesso a una risorsa (disco, un servizio di rete, ecc.). La finta quindi ti consente di fingere di essere quella risorsa esterna, o class o altro.

Non hai davvero bisogno di un framework di oggetti finti, estendi semplicemente la class della funzionalità di cui non vuoi preoccuparti nel test e assicurati che la class che stai testando possa usare la tua simulazione anziché la cosa reale (passala in tramite un costruttore o setter o qualcosa del genere.

La pratica mostrerà quando i mock sono utili e quando non lo sono.

MODIFICA: le risorse di simulazione sono particolarmente importanti in modo da non dover fare affidamento su di esse per esistere durante il test e puoi prendere in giro i dettagli di come esistono e cosa rispondono (come la simulazione di FileNotFoundException o di un servizio web mancante , o vari possibili valori di ritorno di un webservice) … il tutto senza i tempi di accesso lento (il mocking si dimostrerà MOLTO più veloce dell’accesso a tali risorse nel test).

Ho bisogno di un Mock Object Framework?

Certamente no. A volte, scrivere manette a mano può essere piuttosto noioso. Ma per cose semplici, non è affatto male. Applicando il principio dell’ultimo momento responsabile ai quadri di derisione, dovresti passare da un labirinto scritto a mano a un quadro solo quando hai dimostrato a te stesso che i simulatori di scrittura a mano sono più problemi di quanti ne valga la pena.

Se stai iniziando a fare il mocking, saltare direttamente in una struttura raddoppierà almeno la tua curva di apprendimento (puoi raddoppiare una curva?). I quadri di derisione avranno molto più senso quando hai speso alcuni progetti scrivendo manette a mano.

Object Mocking è un modo per creare un object “virtuale” o deriso da un’interfaccia, una class astratta o una class con metodi virtuali. Ti consente di suddividere uno di questi nella tua definizione per scopi di test. È utile per creare un object per cui si fa affidamento su un determinato blocco di codice che stai testando.

Un popolare che mi piace usare si chiama Moq , ma ce ne sono molti altri come RhinoMock e numerosi che non conosco.

Ti permette di testare come una parte del tuo progetto interagisce con il resto, senza build l’intera cosa e potenzialmente senza una parte vitale.

EDIT: Ottimo esempio di wikipedia: consente di testare preventivamente il codice, come un progettista di auto utilizza un manichino di crash test per testare il comportamento di un’auto durante un incidente.

Un altro uso è che ti permetterà di testare altre parti del tuo sistema che non sono ancora state costruite. Ad esempio, se la tua class dipende da un’altra class che fa parte di una funzione su cui sta lavorando qualcun altro, puoi semplicemente chiedere un’interfaccia per lo più completa, un programma per l’interfaccia e solo prendere in giro i dettagli come ti aspetti che funzionino. Quindi, assicurati che le tue ipotesi sull’interfaccia siano corrette (durante lo sviluppo o una volta completata la funzionalità).

Che tu sia o meno un quadro di derisione è utile dipende in parte dalla lingua del codice che stai scrivendo. Con un linguaggio statico, è necessario fare uno sforzo extra per ingannare il compilatore ad accettare i tuoi oggetti finti come sostituto della cosa reale. In un linguaggio tipizzato dynamicmente come Python, Ruby o Javascript, in genere è ansible semplicemente associare i metodi a oggetti o classi arbitrari e passarli come parametro – quindi un framework aggiungerebbe molto meno valore.

2 framework di simulazione consigliati per .net I test delle unità sono Typemock Isolator e Rhino Mock.

Nel seguente link è ansible vedere una spiegazione di Typemock sul motivo per cui è necessario un quadro di simulazione per il test delle unità.