Come gestire i metodi equivalenti di simulazione senza rendere i test fragili?

Question

Come gestire i metodi equivalenti di simulazione senza rendere i test fragili?

#1 da (7 voti)
#2 da (0 voti)

4

Sto scrivendo un test unitario con i mock e sono preoccupato di dover specificare il test. L'idea è che se l'implementazione cambia in modo compatibile, il test non dovrebbe fallire poiché ciò rende il test fragile e scomodo.

Ad esempio, se l'implementazione chiama mock.add("foo") seguita da mock.add("bar") o chiama mock.add("foo","bar") non dovrebbe avere importanza, ma da una prospettiva beffarda tu sei quindi portato a convalidare tutte le possibilità che avrebbero potuto essere implementate. Per i metodi con molti sovraccarichi per comodità (ad es. System.out.println ) ciò sarebbe estenuante!

Quindi, per essere chiari, la mia domanda è: come lavorare con i mock quando sono molti metodi equivalenti che potrebbero essere chiamati dall'implementazione in modo tale che i test risultanti non siano fragili ?

PS- Non penso che sia importante, ma sono su Java usando Mockito, ma mi sembra che ci sia qualche approccio cross-language applicabile che mi manca. Il nostro attuale approccio è quello di effettuare test fragili e risolverli in seguito.

testing unit-testing mocking

posta ArtB 06.10.2016 - 20:00

fonte

2 risposte

Leggi altre domande sui tag testing unit-testing mocking

Ramo a lungo termine: quando e come unirlo? Distingue tra istantanee e versioni ufficiali, mentre distribuisci esattamente ciò che è stato testato

score 7 · Answer 1

La mia opinione è, non verificare che l'implementazione corrisponda alle aspettative. Verifica che il risultato corrisponda alle aspettative. A tal fine, non dovresti aspettarti due chiamate a un metodo add() sul tuo mock durante l'esecuzione del test. Dovresti invece aspettarti, come risultato dell'esecuzione del test, che "pippo" e "barra" siano ora elementi in un semplice elenco, in cui l'implementazione (s) derisa di add() posizionerà qualsiasi valore di parametro passato. È possibile farlo con un'implementazione fittizia con hardcoded e la maggior parte dei framework di simulazione consente anche una semplice implementazione di un membro fittato, sotto forma di un'istruzione lambda o di un altro delegato.

score 0 · Answer 2

Vorrei provare a calcolare il mio codice in modo tale che abbia classi con

un sacco di logica, non molte dipendenze
molte dipendenze ma non molta logica (solo logica di coordinamento)

Mi sembra di sperimentare problemi simili ai tuoi quando ho lezioni in cui io mescolo il coordinamento con la logica importante attuale. A volte puoi evitarlo, a volte non puoi facilmente, ma è bene tenere a mente che questa opzione esiste.

La logica di coordinamento dei test unitari è estremamente macchinosa e fragile. Con le dipendenze di derisione stai solo configurando il tuo stato per arrivare a quella logica molto importante che stai provando a testare. Se si tenta di separare i due diventa più facile testare, perché è possibile testare unitariamente la classe con "molta logica non molte dipendenze" mentre l'integrazione prova la classe che si occupa principalmente di coordinamento.