Stai scrivendo manualmente i test delle unità Prova con l'esempio?

Se scegli casualmente gli input per i test, suppongo che potrebbe essere possibile che tu stia esercitando un errore logico Dimostrazione per Esempio.

Ma i buoni test unitari non lo fanno mai. Invece, trattano in intervalli e casi limite.

Ad esempio, se si dovessero scrivere test unitari per una funzione di valore assoluto che accetta un intero come input, non sarebbe necessario testare ogni possibile valore di input per dimostrare che il codice funziona. Per ottenere un test completo, sono necessari solo cinque valori: -1, 0, 1 e i valori massimo e minimo per il numero intero di input.

Questi cinque valori verificano ogni possibile intervallo e caso limite della funzione. Non è necessario testare ogni altro possibile valore di input (cioè ogni numero che il tipo intero può rappresentare) per ottenere un elevato livello di probabilità che la funzione funzioni per tutti i valori di input.

Qualsiasi test del software è come "Prova per esempio", non solo test delle unità utilizzando uno strumento come JUnit. E questa non è una nuova saggezza, c'è una citazione da Dijkstra del 1960, che dice essenzialmente la stessa:

"Testing shows the presence, not the absence of bugs"

(basta sostituire le parole "mostra" con "prove"). Tuttavia, questo vale anche per gli strumenti che generano dati di test casuali. Il numero di possibili input per una funzione del mondo reale è in genere maggiore di ordini di grandezza rispetto al numero di casi di test che è possibile produrre e verificare rispetto a un risultato previsto entro l'età dell'universo, indipendentemente dal metodo di generazione di tali casi, quindi anche se si utilizza uno strumento generatore per la produzione di molti dati di test, non vi è alcuna garanzia di non perdere l'unico caso di test che potrebbe aver rilevato un determinato errore.

Test casuali possono a volte rivelare un bug che è stato trascurato da casi di test creati manualmente. Ma in generale, è più efficiente realizzare accuratamente test sulla funzione da testare e assicurarsi che si ottenga un codice completo e una copertura di ramo con il minor numero possibile di casi di test. A volte è una strategia fattibile per combinare test manuali e generati casualmente. Inoltre, quando si usano test casuali, bisogna fare attenzione a ottenere i risultati in modo riproducibile.

Quindi i test creati manualmente non sono in alcun modo peggiori dei test generati casualmente, spesso al contrario.

La scrittura manuale dei test è "prova dell'esempio". Ma lo è anche il QuickCheck e, in misura limitata, i sistemi di tipo. Qualsiasi cosa che non sia una verifica formale diretta sarà limitata in ciò che ti dice del tuo codice. Invece, devi pensare in termini di merito relativo degli approcci.

I test generativi, come il QuickCheck, sono davvero buoni per spazzare un ampio spazio di input. È anche molto meglio per affrontare i casi limite rispetto ai test manuali: le librerie di test generative saranno più esperte di quanto non lo siano tu. D'altra parte, ti parlano solo di invarianti, non di output specifici. Quindi per convalidare il tuo programma sta ottenendo i risultati corretti, hai ancora bisogno di alcuni test manuali per verificare che, in effetti, foo(bar) = baz .