Il fornitore di un'interfaccia dovrebbe fornire un'implementazione fittizia per i test?

8

Abbiamo sprecato un sacco di tempo nel nostro ultimo test di integrazione su un bug che credo avrebbe dovuto essere trovato nei test unitari. Il problema era che un'interfaccia / servizio che chiamavamo si comportava in modo diverso da quello che ci aspettavamo e il test di unità non ha riscontrato questo problema perché abbiamo deriso quell'interfaccia per il test dell'unità e il nostro simulato era ovviamente basato sulla nostra errata interpretazione di ciò che l'interfaccia avrebbe fare. Ora potrei essere un po 'arrabbiato con il nostro caro collega che ha fornito l'interfaccia, perché la loro descrizione / specifica di esso (un commento tetra JavaDoc) era ambigua e ha contribuito al nostro fraintendimento. D'altra parte, ho pensato che il problema avrebbe potuto essere evitato se quegli stessi colleghi avessero fornito un'implementazione finta della loro interfaccia che potremmo chiamare nei nostri test unitari. Quindi il bug sarebbe apparso molto prima e si sarebbe potuto evitare parolacce.

Ora, qual è la migliore pratica nell'organizzazione della creazione di oggetti mock tra i team che forniscono e utilizzano le interfacce condivise? Quali sono le tue esperienze?

    
posta Robert Jack Will 03.04.2011 - 12:49
fonte

2 risposte

10

Idealmente, sì.

Chiunque scriva codice utilizzato da altre persone non è tenuto a fornire qualcosa che integri il codice. Tuttavia, se tu vuoi che le persone utilizzino il tuo codice (e tutti dovrebbero scrivere sempre con questa mentalità), un'ampia documentazione pertinente - che può includere esempi - è estremamente utile.

Non penso di aver mai letto documentazione e ho pensato, "Questo è stupido, c'è troppa documentazione." Le persone sono naturalmente dotate di ignorare ciò che ritengono non necessario. Tuttavia, non possiamo semplicemente leggere mentalmente e interpolare la documentazione o i concetti che non sono stati spiegati. Quindi, è sicuro assumere: non c'è niente di troppo buono documentazione. Dovrebbe anche presumere che la persona che legge come un bambino ingenuo (cioè renderlo il più semplice possibile).

Gli esempi su come creare un'istanza e utilizzare una classe sono sempre utili. Sebbene, se il codice si basa troppo sulla documentazione da comprendere, questo è un altro problema (separato).

Questa risposta non dovrebbe essere vista come una potenza di fuoco che giustifica l'urlo al tuo collega di lavoro. È semplicemente una linea guida di ciò che penso sia benefico e dovrebbe essere fatto. Mentre questo è completamente inutile nella tua situazione (anche se sento che la tua domanda è fondamentalmente una sfuriata), la prossima cosa migliore che puoi fare è dare l'esempio e spero che il tuo collega arrivi in giro.

    
risposta data 03.04.2011 - 13:14
fonte
5

Should the provider of an interface also provide a mock implementation for testing?

No , ma il provider dovrebbe anche fornire il codice sorgente per le sue attività di smistamento. Leggendo queste unittest avrai una buona impressione su come dovrebbe essere usata la libreria. Forse puoi aggiungere le unittest ai test del provider per specificare cosa ti aspetti dal provider.

Ci sono molti strumenti di simulazione / framework che possono implementare un falso / stub / mock.

Chiedere al fornitore di un'implementazione simulata non ha una buona relazione costi / benefici perché non può sapere quale parte dell'implementazione falsa deve essere quasi identica all'implementazione reale e quale parte è solo facciata.

Un altro modo è se il provider utilizza i contratti di codec per assicurarsi che la lib sia usata nel modo specificato .

    
risposta data 03.04.2011 - 14:02
fonte

Leggi altre domande sui tag