Unit test di un metodo void

Question

Unit test di un metodo void

#1 da (16 voti)
#2 da (4 voti)
#3 da (1 voti)
#4 da (0 voti)
#5 da (0 voti)

6

Per correggere un bug in un'applicazione, ho modificato un metodo chiamato postLogin aggiungendo una chiamata a un metodo esistente denominato getShoppingCart .

Codice

protected void postLogin() {
  getShoppingCart();
}

Tuttavia, non sono sicuro di quale sia il modo migliore per scrivere un test unitario per postLogin .

Approccio 1

Usa verifica da Mockito per verificare semplicemente che il metodo è stato chiamato.

verify(mock).getShoppingCart();

Approccio 2

Verifica l'effetto collaterale della chiamata al metodo recuperando il valore del carrello degli acquisti dell'utente.

AssertNotNull(user.getShoppingCart());

Un approccio è migliore dell'altro?

testing unit-testing java junit

posta A_B 25.11.2017 - 19:42

fonte

5 risposte

Leggi altre domande sui tag testing unit-testing java junit

In quali condizioni ha senso rompere il codice in molti file o unirli? Quanto tempo investi nell'esplorare nuove tecnologie? [chiuso]

score 16 · Answer 1

Normalmente preferirei il metodo 2.

Perché? Perché, vuoi postLogin per cambiare qualche stato del tuo sistema, ma il modo in cui realizza questo (e i metodi che chiama internamente per questo) è semplicemente un dettaglio di implementazione, niente che il tuo test unitario dovrebbe fare delle ipotesi. Quindi, è meglio eseguire il test semplicemente verificando lo stato finale.

score 4 · Answer 2

Cambiare getShoppingCart in qualcosa di simile a initializeShoppingCart, lo scopo del metodo dovrebbe essere chiaro a chiunque lo legga senza la necessità di controllare il metodo e gli effetti collaterali come questo possono causare alcuni comportamenti sorprendenti per gli utenti del metodo.

Se getShoppingCart si trova in un'altra classe ed è già stato testato sull'unità, userei l'approccio 1 - non c'è bisogno di testare di nuovo ciò che è già stato testato. In questo caso siamo sicuri che getShoppingCart funzioni correttamente e vogliamo solo assicurarci che venga chiamato da postLogin, quindi se qualcuno in futuro rimuove questa chiamata il test fallirà.

Se getShoppingCart è un metodo privato che non può essere testato da solo, allora userò l'approccio 2, per assicurarmi che quando postLogin viene chiamato, la funzionalità desiderata di getShoppingCart venga eseguita come previsto.

score 1 · Answer 3

Quando si verifica una chiamata di funzione (nulla o no) che ha un effetto collaterale, è più completo verificare che l'effetto collaterale non si verifichi solo, ma controllare che l'effetto collaterale (output di sistema o cambiamento di stato) sia quello desiderato.

score 0 · Answer 4

Non discuterò il tuo progetto, ma nel tuo caso andrei per il primo approccio perché il test unitario è per testare quali metodi tecnicamente non dipendono dal loro lavoro nel dominio, cioè, che cosa il tuo metodo postLogin fa ? Tecnicamente chiama getShoppingCard quindi devi testare che sta davvero chiamando getShoppingCard , vorrei anche creare un altro test per getShoppingCard per testare cosa fa e se ha effetti collaterali lo controllerò all'interno di quel nuovo test.

score 0 · Answer 5

Hai un bug in postLogin. Quindi la prima cosa che dovresti fare è creare un test unitario che, una volta chiamato postLogin senza il set di informazioni previsto, "fallirà".

Dall'idea precedente, un'altra alternativa del 2 proposto è quella di iniettare le informazioni sul carrello degli acquisti come parametro. Se non si dispone delle informazioni corrette, si genera un'eccezione non controllata. Questo renderà chiaro che senza i dettagli corretti, il tuo metodo è condannato.

Questo richiederà un piccolo cambiamento in cui il client che chiama il postLogin in questo momento è richiesto anche per passare le informazioni del carrello. Per me questo è ancora coerente ora che vedi che sono accoppiati. Questo accoppiamento verrà effettuato dal chiamante.

Quindi non avresti nemmeno bisogno di testare getShoppingCart all'interno di postLogin perché il vero metodo sotto test è postLogin. È quello che ha il bug e l'unico che richiede una corretta correzione e validazione. Con la dipendenza iniettata, sarai in grado di testarlo facilmente in condizioni diverse e confermare che non viene emesso alcun errore.