Test con parametri - Quando e perché li usi?

Di recente al lavoro abbiamo riscontrato alcune differenze di opinione in merito ai test con parametri . Normalmente utilizziamo uno stile TDD (o almeno proviamo a farlo), quindi comprendo i vantaggi di tale approccio. Tuttavia, faccio fatica a vedere i guadagni test parametrizzati. Per riferimento, lavoriamo su un servizio e le sue librerie che sono esposte tramite un'interfaccia RESTful.

Quello che ho visto finora sono i test che, almeno usando JUnit in Eclipse:

• Mancanza di dettagli: quando un test fallisce è molto difficile vedere i parametri che lo hanno causato
• Spesso complicato da creare
• Tendono a essere creati dopo che il codice è stato scritto - rigorosamente non uno svantaggio in quanto tale ma le persone iniziano con test parametrici in mente quando iniziano un pezzo di codice?

Se qualcuno ha qualche esempio di dove sono veramente utili o anche qualche buon suggerimento per usarli sarebbe fantastico. Voglio essere sicuro di non essere solo ostinato perché personalmente non scelgo di usarli e vedere se sono qualcosa che dovremmo considerare come parte del nostro arsenale di test.

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 DOE (Design of Experiments), che consente di generare il probabile elenco di valori di parametro che devono essere testati.

L'idea è che, anche se non si esegue un test esaustivo, la maggior parte dei difetti provoca una "regione di errore" anziché un errore di punto isolato. L'approccio DOE Phadke sostiene l'uso di array ortogonali che campionano lo spazio dei parametri abbastanza finemente da colpire tutte le possibili regioni di guasto.

Probabilmente i guasti isolati non verranno identificati, ma generalmente sono inferiori alle regioni di guasto.

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

Possono essere utili per garantire che il 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 anche valori null e 0, stringhe vuote, numeri grandi, stringhe lunghe, strani caratteri Unicode, ecc., Funzionino bene.

Esistono almeno due tipi di test con parametri, almeno in JUnit 4.8. Questi sono: Parameterized Test ( @RunWith(Parameterized.class)) che richiede un'origine dati, che genera / legge configurazioni di parametri predefiniti e Teorie ( @RunWith(Theories.class)) che, dati uno o più set di possibili input per tipo di argomento, possono esercitare la specifica di determinati metodi. Sembra più o meno così:

• specifica alcuni possibili valori ( @DataPoints) per argomenti stringa (come null, stringa vuota, stringa non vuota, stringa davvero lunga)
• specificare alcuni valori possibili ( @DataPoints) per gli argomenti della classe Animal (come null, Dogistanza, Catistanza, Birdistanza)
• preparare @Theoryche accetta un Stringparametro e un Animalparametro. verrà eseguito con ogni possibile combinazione dei possibili valori dei parametri (nell'esempio dato che sarebbe 4x4 = 16 combinazioni, incluso ( null, null))
• se il metodo sotto test non può accettare alcuna combinazione, utilizzare Assume.assumeThatle importazioni statiche per filtrare le combinazioni non valide (ad es. quando si desidera verificare il comportamento del metodo per stringhe non vuote, una delle prime righe sarebbe "presuppone che non sia nulla"

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

Esempio generico:

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

• Applica lo stesso scenario su argomenti diversi. Abbiamo uno scenario che funziona con l' Animaloggetto e l'avere un sacco di sottoclassi quali Dog, Cat, Bird. Creare un elenco degli animali disponibili e testare lo scenario su di essi.

Calcestruzzo per servizio web:

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

I test con parametri funzionano bene per testare funzioni / caratteristiche che hanno input semplici quando si desidera testare vari input.

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

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

Ma ho visto alcuni orrori dei test con parametri. No, Virginia, la tua suite di test non dovrebbe aver bisogno dei propri test unitari.