"Tutto ciò che può andare storto andrà male" - Murphy's Law. quindi è necessario testare tutti i casi di eccezioni condizionali? [chiuso]

Sì! Ogni blocco di codice dovrebbe essere testato. Ma come lo test? Per unità Test al primo posto,

bene, per far sì che il codice sia testabile, è un'altra teoria, è una sorta di tecnica di programmazione. Non puoi lasciare che il tuo codice diventi odore.

1. Testa il tuo codice parte per funzione.
2. La tua funzione deve essere specifica, uno scopo, semplice, non complessa.
   per esempio. non rendere variabile globale nella tua funzione, altrimenti (non testabile)
3. La tua funzione deve essere comprensibile.
4. La tua funzione si associa in modo approssimativo, meno dipendenza, in modo che tu possa testarla facilmente. ecc.ecc ....

Una volta migliorato lo stile del codice, i casi di test, casi angolari potrebbero essere facilmente testati.

Ecco un buon articolo su come rendere il tuo codice meno profumato. Spero che ti aiuti.

Considera l'analisi copertura del codice . Nella mia esperienza è stato un modo abbastanza efficace per scoprire casi d'uso non testati.

Quando i test hanno già una copertura di codice elevata, usare questo approccio per scoprire buchi può essere anche divertente - perché i casi rimanenti risultano piuttosto non ovvi (o, ancora più interessanti, potrebbero corrispondere a bug nella specifica).

• Semplicemente non dare per scontato che l'analisi di copertura garantirà di coprire tutti i casi rilevanti. Ad esempio, non ti proteggerà dai problemi mancanza di funzionalità o concorrenza .

La cosa da tenere a mente è che potrebbe essere complicato scavare in ogni caso possibile. Immagina un'applicazione progettata per produrre "Hello World" se e solo se è giovedì e piove - per testarlo, dovresti aspettare fino a giovedì quando piove? o simulare le condizioni necessarie. Potrebbe essere troppo sforzo per giustificare i rischi che eviterai facendoli coprire nei test.

Un'altra cosa da considerare è quanto tempo richiede il test. Se è necessario un anno per testare completamente l'applicazione, è meglio lasciar perdere l'idea (a meno che non si tratti di un prodotto mission critical)

Lo trovo molto vero. A volte tendo ad essere pigro e non testare certe righe di codice, ma quasi mai fallisce nel tornare indietro e colpirmi.

Se stai scrivendo il codice OO. Ecco gli input basati sul mio apprendimento.

• Utilizza Rasoio di Occam . Questo è il modo più semplice per implementarlo.
• Dividi tutto ciò che può essere diviso in più classi o mixaggi finché non vedi che ogni classe o mixin sta facendo esattamente una cosa. Questo è il rispetto di SRP .
• Per ogni mixin / classe scrivi almeno un caso di test che copre inizialmente ogni funzione.
• Se stai utilizzando alcune librerie di terze parti, vedi se ci sono possibilità che tali funzioni possano restituire risultati inaspettati dalla documentazione.
• Ora guarda se / for / while / case e costrutti simili per vedere se è coperto nel tuo caso di test. Se non scrivi più casi di test.
• Verifica se una linea può fallire a causa di cose come NullPointerException o tipo di errore non definito dell'oggetto. Tipicamente linee dopo una sorta di creazione di oggetti o cose che dipendono dall'uso della libreria per impostare il tuo oggetto.
• Utilizza il test della scatola nera, in cui testerai tutte le funzioni in base alle condizioni del pubblico disponibile o meno. La maggior parte dei framework di testing ritiene che testare le interfacce pubbliche faccia (test white box) e che alcune lingue non ti consentano l'accesso a interfacce private. In queste situazioni prova a testare le funzioni private tramite funzioni pubbliche.
• Utilizza alcuni strumenti automatici che possono testare la copertura del codice.

Anche dopo questo ci saranno alcuni scenari che non si possono facilmente testare, specialmente quelli relativi all'ambiente. È possibile ottenere il peer di revisione del codice da un programmatore esperto o eseguire i test case in tutti gli ambienti possibili.

Non si può mai essere completamente sicuri che ogni caso sia coperto. Se hai trascorso molto tempo con il codice mentre è sviluppato, acquisisci sicurezza su di esso. Una volta che hai abbastanza confidenza, rilascialo coraggiosamente. Le cose torneranno, visto che avresti letto il tuo codice 100 volte, puoi sistemare le cose molto velocemente e sarai in grado di immaginare altri posti che accadrà. Per ogni bug che ritorna, coprilo con casi di test.

Se tutti sapessero come spiegare tutto , ci sarebbe fondamentalmente una versione del software, non sarebbe necessaria alcuna manutenzione, i tester non sarebbero richiesti, ecc. Non si può seguire un set di linee guida che ti daranno una risposta magica in bianco e nero perché l'elenco degli elementi da testare si basa su un componente multi-variabile (codice).

La cosa migliore che puoi fare è imparare . Farai degli errori e dimenticheresti di fare le cose; fare uno sforzo cosciente per non fare lo stesso errore due volte. Se riesci a fare ciò, probabilmente sei migliore del normale ingegnere del software.

Forse

Non puoi dare conto di tutti i casi eccezionali a meno che tu non abbia un sacco di tempo e denaro. Più interconnessioni in un sistema software sono tanto più complesse e più ci vuole per coprire anche i casi di test standard. Non stiamo nemmeno necessariamente parlando del codice che hai scritto. Ricorda che ogni volta che il tuo software non funziona semplicemente a corto di memoria (che non cresce) avrai molti più casi d'eccezione. L'accesso alla rete, al disco, alla visualizzazione, a qualsiasi altro dispositivo può causare un'eccezione. La crescente memoria può causare un'eccezione. In alcuni casi, persino il rilevamento che il software sia stato interrotto in modo errato può essere un caso eccezionale. La domanda è: hai davvero bisogno di coprire ogni eccezione.

Sì

Se stai lavorando su un software in cui le vite sono in bilico, letteralmente. Quindi sì, probabilmente devi almeno considerare ogni caso di eccezione. Software di chirurgia, software Space Shuttle, software di sistema d'arma, ecc. In ognuno di questi casi c'è spesso un'analisi esplicita di quali sono tutte le eccezioni e se hanno bisogno di essere coperte. Questi tipi di progetti spesso finiscono per spendere molto più tempo e denaro per coprire questi casi. Questo è il costo per coprire "tutti" i casi di eccezione.

No

Stai lavorando a un software di social networking. Un'app di Facebook, un'app per iPhone, qualche sito per appassionati di motociclette, ecc. Questo tipo di software di solito non garantisce il tipo di considerazione di cui ho parlato sopra. Di solito c'è un costo per arrivare sul mercato in ritardo, e coprire anche alcuni dei casi eccezionali può essere proibitivo. Questo può spesso essere una decisione che avrà implicazioni commerciali, specialmente in una startup. Coprite tutti questi casi e fate fallire la vostra azienda o perdete una grande porzione di entrate?

Dipende

Quindi la risposta è "dipende". Dipende dalle esigenze dell'azienda, dal costo di tali eccezioni, dal costo del tempo e dallo sforzo supplementari necessari per evitare tali eccezioni e il tempo necessario.

posizione

Idealmente si ottiene un equilibrio. Utilizzare pratiche come test automatizzati per ottenere almeno la massima copertura del codice possibile senza costi eccessivi in termini di tempo e denaro. È possibile utilizzare pratiche come test unitari, test funzionali, test fuzz, ecc; in modo che il software non sia troppo buggato, che sia facile da mantenere ed estendere, e così puoi guardarlo e prendere un certo orgoglio in ciò che hai scritto.

La cosa più importante è che succedano cose che non hai previsto, e quindi non codificate.

È molto importante che il tuo programma lo gestisca correttamente. Devi scegliere se "è successo qualcosa di inaspettato" è abbastanza brutto che il programma dovrebbe chiudersi con grazia immediatamente per un'ispezione manuale o quale altro potrebbe essere la procedura corretta.

Personalmente ho scoperto che l'approccio "fail-fast" è il modo migliore per ottenere un buon comportamento del programma dopo alcune iterazioni.