Le migliori pratiche hanno sempre uno scopo, una ragione dietro di esse. È sempre una buona idea considerare questi motivi nel tuo design, specialmente quando stai cercando di decidere come e quanto sia difficile seguire queste best practice.
In questo caso, il ragionamento principale alla base del test di ogni singolo test è che se la prima cosa fallisce, la seconda non verrà testata. Dal momento che troppi opinion maker sembrano trovare il merito di rompere tutto fino al più piccolo bit possibile e avvolgendo ogni cosa nel modo più gonfio possibile, questo ha dato origine all'idea che ogni test dovrebbe contenere un singolo assert.
Non seguirlo ciecamente. Anche se ogni test dovesse testare una cosa, dovresti comunque riflettere su quanto grande o piccola dovrebbe essere ogni "cosa", e per farlo devi tenere a mente perché vuoi che ogni test venga prova una cosa - per assicurarti che un bug nella prima cosa non lasci la seconda cosa non testata.
Quindi, è necessario chiedersi: "ho davvero bisogno di questa garanzia qui?"
Diciamo che c'è un bug nel primo caso di test - il codice di risposta HTTP non è 200 . Quindi inizi a hackerare il codice, capisci perché non hai ricevuto il codice di risposta che dovresti avere e risolvi il problema. E ora cosa?
- Se esegui di nuovo il test manualmente, per verificare che la tua soluzione risolva il problema, dovresti imbatterti in qualsiasi altro problema nascosto dal primo errore.
- Se non lo esegui manualmente (forse perché impiega troppo tempo?) e ti basta spingere la tua correzione in attesa che il server di test automatico esegua tutto, allora potresti voler inserire diversi asser in diversi test. I cicli in questo caso sono molto lunghi, quindi vale la pena di fare lo sforzo di scoprire il maggior numero di errori in ogni ciclo.
Ci sono poche altre cose da considerare:
Dipendenze delle asserzioni
So che i test che hai descritto sono solo un esempio ei tuoi test effettivi sono probabilmente più complicati, quindi quello che sto per dire potrebbe non essere valido con la stessa forza nei test reali, ma potrebbe essere ancora un po ' efficace in modo da poterlo considerare.
Se si dispone di un servizio REST (o qualsiasi altro protocollo HTTP) che restituisce risposte in formato JSON, di solito si scrive una semplice classe client che consente di utilizzare i metodi REST come metodi regolari che restituiscono oggetti regolari. Supponendo che il cliente abbia test separati per assicurarsi che funzioni, avrei abbandonato i primi 3 assert e ne avrei conservati solo 4!
Perché?
- La prima affermazione è ridondante - la classe client dovrebbe generare un'eccezione se il codice di risposta HTTP non è 200.
- La seconda asserzione è ridondante - se la risposta è vuota, l'oggetto risultato sarà nullo o qualche altra rappresentazione di un oggetto vuoto, e non avrai nessun posto dove mettere la chiave X.
- Il terzo assert è ridondante - se il JSON non è valido, ottieni un'eccezione quando provi ad analizzarlo.
Quindi non è necessario eseguire tutti questi test: basta eseguire il quarto test e, se uno qualsiasi dei bug che i primi tre cercano di rilevare, il test fallirà con un'eccezione appropriata prima ancora di ottenere l'asserzione effettiva.
Come si desidera ricevere i report?
Supponiamo di non ricevere email da un server di prova, ma invece il reparto QA esegue i test e notifica i test non riusciti.
Jack del QA bussa alla tua porta. Dice che il primo metodo di test non è riuscito e che il metodo REST ha restituito un codice di risposta errato. Lo ringrazi e inizi a cercare la causa principale.
Poi arriva Jen dal QA e dice che il terzo metodo di test non è riuscito - il metodo REST non ha restituito un JSON valido nel corpo della risposta. Le dici che stai già osservando quel metodo e credi che la stessa cosa che ha causato il ritorno di un brutto codice di uscita ha anche causato il ritorno di qualcosa che non è un JSON valido, e assomiglia più a una traccia dello stack di eccezioni.
Ritorni a lavorare, ma poi arriva Jim dal QA, dicendo che il quarto metodo di test è fallito e che non c'è la chiave X nella risposta ...
Non puoi nemmeno cercare il motivo perché è difficile guardare il codice quando non hai uno schermo di computer. Se Jim fosse stato abbastanza veloce avrebbe potuto schivarlo in tempo ...
Le e-mail dal server di test sono più facili da respingere, ma ancora - preferiresti semplicemente ricevere una notifica UNA VOLTA che qualcosa non funziona con il metodo di prova e guardare i log di test rilevanti da te ?