I test unitari dovrebbero superare tutti i casi e tutti i casi di fallimento?
Ad esempio, immagina di avere un test Widget_CannotActiveWidgetIfStateIsCancelled .
E diciamo che ci sono 25 stati possibili.
Posso fare a meno di provare solo che non posso attivare il mio widget quando stato == Cancellato, o devo anche provare che POSSO attivarlo in ciascuno degli altri 24 stati?
Normalmente lasceresti che i nomi dei tuoi test parlassero. Quello che voglio dire è, se puoi avere questi due test:
When_state_is_canceled_then_cannot_activate_widget When_state_is_not_canceled_then_can_activate_widget E se entrambi i test sopra sono una descrizione accurata del comportamento, allora no, non è necessario scrivere test per tutti i 25 stati possibili, perché ci sono solo 2 stati che contano davvero, "cancellati" e " non cancellato ". Nell'effettiva implementazione di "non cancellato", ovviamente, dovrai scegliere un altro specifico stato. Da un punto di vista della pura copertura del codice, avrai una copertura completa in questo modo.
D'altra parte, dovresti anche provare a prevedere come potrebbe cambiare la SUT. Forse oggi ci sono 24 stati che si comportano tutti allo stesso modo, ma tra tre settimane le regole potrebbero cambiare in un modo molto sottile che si rompe o non è coperto dal test che hai scritto oggi.
Una cosa che a volte ho fatto è, nel test "negativo", avere un ciclo che enumera tutti gli stati possibili, esclude quelli che non si applicano e li verifica ciascuno in sequenza. Questo è il modo pigro, ma è un po 'meno traballante che scegliere uno stato a caso.
Ma la maggior parte delle volte preferisco scrivere test di stile Context / Specification , che rimuove completamente questa ambiguità rendendo ogni stato possibile una classe di test separata, e sì, ciò significa testare tutti e 25 gli stati, anche se ci sono molti modi in cui è possibile utilizzare l'ereditarietà o la composizione nei test per ridurre il bloat del codice pur mantenendo i test per tutti gli stati.
Non c'è una regola, puoi "cavartela" qualunque cosa tu voglia, è solo una questione di quanto vuoi che i test siano completi, il che probabilmente dipenderà da cose come quanti altri sviluppatori stanno lavorando codice, qual è il costo di ciascun difetto per l'azienda, la frequenza di rilascio, ecc. Se si sta tentando di eseguire TDD o BDD, utilizzare contesto / specifica per ciascuno stato. Se stai solo cercando di ottenere una copertura del codice a metà decente, prova solo uno stato "on" e uno "off".
Mentre certamente dovresti verificare che l'unità non funzioni correttamente oltre a passare correttamente, non c'è motivo di scrivere un test che non aggiunga fiducia al codice.
Tuttavia, se la tua "unità" ha venticinque stati possibili, potrebbe essere meglio pensare a ogni stato come un'unità distinta e costruire i tuoi test in modo appropriato. (non dimenticare che i tuoi test possono condividere il codice laddove appropriato).
Dipende dall'implementazione, ma molto probabilmente dovresti scrivere due test: uno per Cancelled e uno per qualsiasi degli altri 24 stati.
Perché è abbastanza? Perché tutti gli altri 24 stati formano una classe di equivalenza. Il test di questi due casi dovrebbe coprire tutti i rami nell'implementazione di Activate .
Si noti inoltre che questo approccio è ciò che si otterrebbe se si fosse utilizzato lo sviluppo basato su Test. L'altro approccio - scrivendo 25 casi di test - è una forma di test black box che generalmente porta a test multipli che testano la stessa cosa.
Leggi altre domande sui tag unit-testing