Test parametrizzati - Quando e perché li usi?

Il problema con il test di qualsiasi software è che la complessità esplode abbastanza rapidamente. Il fatto è che non puoi testare tutte le possibili combinazioni di parametri passati ai tuoi metodi. Phadke sostiene un approccio di Design of Experiments (DOE), che consente di generare l'elenco probabile di valori dei parametri che devono essere testato

L'idea è che, anche se non si sta testando in modo esaustivo, la maggior parte dei difetti causa una "regione di errore", piuttosto che un guasto a un punto isolato. L'approccio DOE Phadke sostiene l'uso di campioni di array ortogonali con lo spazio dei parametri abbastanza fine da colpire tutte le possibili regioni di errore.

Probabilmente non verranno identificati errori isolati, ma questi sono generalmente meno delle regioni di errore.

L'approccio DOE ti offre un modo sistematico di scegliere i valori dei parametri da variare.

Possono essere utili per garantire che il tuo codice gestisca non solo il percorso felice, ma anche i casi limite. Dopo aver saputo che il tuo codice funziona con variabili normali, parametrizza il caso di test e assicurati che null e 0, stringhe vuote, numeri grandi, stringhe lunghe, caratteri Unicode strani, ecc., Funzionino bene.

Ci sono almeno due versioni di test parametrizzati, almeno in JUnit 4.8. Quelli sono: Test parametrizzati ( @RunWith(Parameterized.class) ) che richiede un'origine dati, che genera / legge configurazioni di parametri predefinite, e Teorie ( @RunWith(Theories.class) ) che, dato uno o più insiemi di possibili input per tipo di argomento, possono esercitare la specificazione di determinati metodi. Sembra più semplice di questo:

• specifica alcuni valori possibili ( @DataPoints ) per argomenti stringa (come null , stringa vuota, stringa non vuota, stringa veramente lunga)
• specifica alcuni valori possibili ( @DataPoints ) per gli argomenti della classe Animal (come null , Dog istanza, Cat istanza, Bird istanza)
• prepara @Theory che accetta un parametro String e un parametro Animal . verrà eseguito con ogni possibile combinazione dei possibili valori dei parametri (in questo esempio sarebbe 4x4 = 16 combinazioni, tra cui ( null , null ))
• se il metodo in prova non accetta alcune combinazioni, usa Assume.assumeThat importazioni statiche per filtrare le combinazioni non valide (ad esempio, quando si desidera verificare il comportamento del metodo per stringhe non vuote, una delle prime righe dovrebbe essere "supporre che sia non null "

Come scritto prima - non ha senso testare ogni possibile combinazione di ogni metodo (esplode i set di test, immagina di testare un metodo con 5 parametri, ognuno dei quali ha solo 5 possibili valori: 5 ** 5 - > oltre 3000 esecuzioni di test!), ma per i metodi mission-critical (come i metodi API) lo incoraggerei, solo per essere al sicuro ...

Esempio generico:

• Metodi con argomenti stringa. Utilizzare i test parametrizzati per testare diversi input e le loro uscite previste. È molto più pratico avere un elenco di coppie (input, previsto) rispetto a scrivere un TC per ogni coppia.

• Applicare lo stesso scenario su argomenti diversi. Abbiamo uno scenario che funziona con l'oggetto Animal e abbiamo un sacco di sottoclassi come Dog , Cat , Bird . Crea una lista degli animali disponibili e prova lo scenario su di loro.

Concrete per il webservice:

• Dall'esempio degli argomenti stringa sopra. Prova cosa succede con argomenti diversi dello stesso tipo ma con valori diversi.

I test parametrizzati funzionano bene per testare funzioni / caratteristiche che hanno un input semplice quando si desidera testare una varietà di input.

Non funzionano bene per testare funzionalità diverse e input complessi. Non dovrebbero essere usati come una struttura di convenienza per scrivere meno codice.

Un caso in cui utilizzo molti test parametrizzati in un modo TDD-ish è la scrittura di parser: posso iniziare con un elenco se input e output previsti e quindi scrivere il codice in modo che passi tutti i test case.

Ma ho visto alcuni orrori di test parametrizzati. No, Virginia, la tua suite di test non dovrebbe aver bisogno dei propri test di unità.