Qual è il modo migliore per testare che gestiamo i fallimenti in modo appropriato?

Simula il fallimento / situazione eccezionale.

I tuoi oggetti simulati sono manichini dei crash test e sai già cosa può andare storto, non dovrebbe essere difficile da emularlo (lo sai perché lo hai già preparato, se non lo fai, bene, tu scoprirò presto;). E ... è sempre incredibilmente divertente scollegare fisicamente il server del database mentre i processi sono in esecuzione. In realtà non è scalabile come metodo di test, ma è fantastico anche se lo fai solo una volta.

Considera questo esempio banale / eccessivamente semplicistico:

• Class A fa qualcosa e lancia un'eccezione OMGSomethingBroke se qualcosa va storto.
• Class B chiama Class A , e nel caso qualcosa si rompa, cattura l'eccezione e la registra (o qualsiasi altra cosa).

Quello che devi fare è creare una simulazione di Class A , chiamiamola Mock A che non fa altro che lanciare l'eccezione OMGSomethingBroke . Mock A e Class A dovrebbero implementare la stessa interfaccia, e questo è tutto. Hai emulato l'errore e ora puoi passare a testare Class B . Chiamare Mock A anziché Class A e verificare se gestisce correttamente l'errore.

I test possono essere eccezionalmente semplici se il tuo progetto è solido (sì, entrambi i giochi di parole sono pensati).

Ho appena trovato un Udacity molto interessante corso, Test del software (CS258) - Come fare fallire il software :

When writing software, destruction can be just as valuable as creation. Learn how to catch bugs and break software as you discover different testing methods that will help you build better software.

Il corso ha un ambito più ampio della tua domanda , ovviamente, ma il messaggio principale nel suo riassunto si applica: Breaking stuff is fun! (Bene, e un buon modo per testare il software).

Questo è uno dei tanti motivi per cui la modularizzazione è una buona idea.

Il tuo test dovrebbe verificare il comportamento di un bit di codice e uno solo. In questo caso, è il codice che invia email quando un diverso bit di codice genera un errore. Quindi quello che fai è collegare una versione di simulazione del altro bit di codice che crea un errore, al tuo attuale gestore di errori di produzione, e quindi verificare che invii email. (Puoi anche sostituire il codice di invio dell'email con una versione fittizia, quindi in realtà non invia la posta ma solo i rapporti che lo avrebbero fatto - rende il test molto più semplice e veloce.)

In questo modo, tutti sono contenti: il tuo gestore degli errori è testato, il tuo codice di produzione non causa mai errori (che tu conosci), e sai ancora che potrebbe succederebbe se fosse . Se il tuo codice base non supporta connessioni così flessibili, beh questo è uno dei motivi principali per cui dovrebbe.

So, how do we test something what we never want to actually happen?

A volte, non puoi, a volte non vuoi. Boeing non invia intenzionalmente un jet prototipo a un'immersione a 100 piedi da terra per testare vari eventi di tipo "non può accadere". Una centrale nucleare non sta andando intenzionalmente a guidare la centrale elettrica oltre il punto di non ritorno per vedere se i backup terziari funzionano.

Questo sembra testabile. Getta un'eccezione che sai che non è stata catturata. Tranne che tramite un catch-all (ad esempio catch (...) ), quasi certamente non stai rilevando un'eccezione di tipo BogusExceptionForTestPurposesOnly . Quindi gettalo in qualche codice di test. Assicurati solo che questo codice di test non faccia mai parte del deliverable.

Aggiungi una speciale richiesta "rompi le regole" per eseguire il debug di build e invocarla. Ad esempio, aggiungi una richiesta "non lanciata" e ottieni una condizione unica che ritieni debba essere ignorata.