È meglio avere uno a

• Suite di test deterministico, che si traduce nel successo degli stessi test
• Suite di test non deterministico, che potenzialmente copre probabilmente più casi

?

Esempio: si scrive una suite di test per testare la funzionalità del controller in un'applicazione MVC. Il controller richiede i dati dell'applicazione da un database come input durante il test. Ci sono due opzioni per fare questo:

• Si hardcode quali righe del database di test sono selezionate come input (ad es. La decima e la quarta riga)
• Si utilizza un generatore di numeri casuali per selezionare in modo pseudocasuale i dati dal database (due righe selezionate da un generatore di numeri casuali)

Il primo è deterministico: ogni esecuzione del test per la stessa revisione del codice dovrebbe produrre lo stesso risultato. Il secondo non è deterministico: ogni esecuzione della suite di test ha la possibilità di produrre un risultato diverso. I dati raccolti in modo casuale potrebbero tuttavia essere una migliore rappresentazione dei casi limite di dati. Potrebbe simulare meglio un utente che fornisce ai nostri controller dati imprevedibili?

Quali sono i motivi per scegliere l'uno rispetto all'altro?

Quando ogni esecuzione della suite di test ti dà la possibilità di produrre un risultato diverso, il test è quasi del tutto inutile: quando la suite ti mostra un bug, hai un'alta probabilità di non poterlo riprodurre e quando provi a risolvere il bug, non è possibile verificare se la correzione funziona.

Pertanto, quando ritieni di dover utilizzare un qualche tipo di generatore di numeri casuali per generare i tuoi dati di test, accertati di inizializzare sempre il generatore con lo stesso seed o di conservare i dati di test casuali in un file prima di inserirlo nel test, così puoi rieseguire nuovamente il test con esattamente gli stessi dati dell'esecuzione precedente. In questo modo, puoi trasformare qualsiasi test non deterministico in uno deterministico.

EDIT: l'utilizzo di un generatore di numeri casuali per raccogliere alcuni dati di test è IMHO a volte un segno per essere troppo pigro sulla raccolta di buoni dati di test. Invece di lanciare 100.000 valori di test scelti casualmente e sperare che questo sia sufficiente per scoprire tutti i bug gravi per caso, utilizzare meglio il cervello, scegliere da 10 a 20 casi "interessanti" e usarli per la suite di test. Ciò non solo porterà a una migliore qualità dei test, ma anche a prestazioni molto più elevate della suite.

Sia deterministico che non deterministico hanno un posto

Le dividerei come segue:

Test unitari.

Questi dovrebbero avere test deterministici e ripetibili con gli stessi stessi dati ogni volta. I test unitari accompagnano sezioni di codice specifiche e isolate e dovrebbero testarle in modo deterministico.

Prove di stress funzionali e di input.

Questi possono usare l'approccio non deterministico con le seguenti avvertenze:

• tale fatto è chiaramente delineato e richiamato
• i valori casuali selezionati vengono registrati e possono essere riprovati manualmente

Tutti e due.

I test deterministici e non deterministici hanno casi d'uso diversi e valori diversi per la tua suite. Generalmente il non deterministico non può fornire la stessa precisione del test deterministico, che è diventato lentamente "il test non deterministico non fornisce alcun valore". Questo è falso Possono essere meno precisi, ma possono anche essere molto più ampi, il che ha i suoi vantaggi.

Facciamo un esempio: scrivi una funzione che ordina un elenco di numeri interi. Quali sarebbero alcuni dei test unitari deterministici che potresti trovare utili?

• Un elenco vuoto
• Un elenco con un solo elemento
• Un elenco con tutti lo stesso elemento
• Un elenco con più elementi univoci
• Un elenco con più elementi, alcuni dei quali sono duplicati
• Un elenco con NaN, INT_MINeINT_MAX
• Un elenco che è già parzialmente ordinato
• Un elenco con 10.000.000 di elementi

E questa è solo una funzione di ordinamento! Certo, potresti sostenere che alcuni di questi non sono necessari o che alcuni di questi possono essere esclusi con un ragionamento informale. Ma siamo ingegneri e abbiamo visto esplodere il ragionamento informale in faccia. Sappiamo di non essere abbastanza intelligenti da comprendere completamente i sistemi che abbiamo costruito o mantenere completamente la complessità nella nostra testa. Ecco perché scriviamo test in primo luogo. L'aggiunta di test non deterministici afferma che potremmo non essere necessariamente abbastanza intelligenti da conoscere a priori tutti i buoni test. Lanciando dati semi-casuali nella tua funzione, hai molte più probabilità di trovare un caso limite che ti sei perso.

Ovviamente, ciò non esclude nemmeno i test deterministici. I test non deterministici aiutano a trovare bug in enormi parti del programma. Una volta trovati i bug, tuttavia, è necessario un modo riproducibile per dimostrare che è stato risolto. Così:

• Usa test non deterministici per trovare bug nel tuo codice.
• Utilizzare test deterministici per verificare le correzioni nel codice.

Si noti che ciò significa che molti consigli solidi sui test unitari non si applicano necessariamente ai test non deterministici. Ad esempio, devono essere veloci. I test delle proprietà di basso livello dovrebbero essere veloci, ma un test non deterministico come "simula un utente facendo clic in modo casuale sui pulsanti del tuo sito web e assicurati di non avere mai un errore 500" dovrebbe favorire la completezza rispetto alla velocità. Basta eseguire un test come quello indipendentemente dal processo di compilazione in modo da non rallentare lo sviluppo. Ad esempio, eseguirlo nella propria casella di gestione temporanea privata.

Non vuoi davvero deterministico contro non deterministico.

Quello che potresti desiderare è "sempre lo stesso" vs. "non sempre lo stesso".

Ad esempio, potresti avere un numero di build che aumenta con ogni build e quando vuoi alcuni numeri casuali, inizializzi un generatore di numeri casuali con il numero di build come seed. Quindi ogni build, fai i tuoi test con valori diversi, dandoti più possibilità di trovare bug.

Ma una volta trovato un bug, tutto ciò che devi fare è eseguire il test con lo stesso numero di build ed è riproducibile.