In precedenza, Joseph Morgan ha discusso in dettaglio l'idea di unit testing in JMP. Alcune letture eccellenti:
Per semplificare le cose in questo blog, utilizzo la terminologia di Whittaker (2000) per definire i test unitari.
Test unitari: dominio di input
Il termine "test unitario" significa testare singoli componenti software o una raccolta di componenti. I tester definiscono il dominio di input per le unità in questione e ignorano il resto del sistema.
Concentriamoci sul secondo pezzo, dove i tester definiscono il dominio di input. Cosa succede se abbiamo una funzione che vogliamo testare, ma vogliamo trattare i singoli argomenti come unità?
Ad esempio, prendi la funzione Beta Distribution da JSL (screenshot da Scripting Index). La funzione Beta Distribution è usata per modellare variabili casuali che sono limitate tra 0 e 1, spesso usate nelle statistiche bayesiane.
Potremmo fissare alfa e beta a un valore simile a 0,5 e testare diversi valori di q.
alpha = 0.5;
beta = 0.5;
Beta Distribution( 0.5, alpha, beta );
Beta Distribution( -1, alpha, beta );
Beta Distribution( 0, alpha, beta );
Ora, determinare cosa ci aspettiamo per ogni chiamata di funzione alla funzione Beta Distribution è un post di blog a sé stante (noto come problema dell'oracolo). Tuttavia, supponendo di sapere cosa ci aspettiamo (in questo caso, 0,5, un valore mancante e 0), possiamo testare q. Ciascuno degli input può essere verificato singolarmente in modo simile in questo modo, come alpha, beta e persino theta e sigma.
Test OFAT (un fattore alla volta)
Cosa significa se ci concentriamo su un argomento alla volta? Impostando gli altri argomenti su un valore fisso (come quello predefinito) e modificando il valore di un argomento sembra un test tramite OFAT.
Quando veniamo introdotti a esperimenti progettati (tipici), discutiamo le insidie di OFAT. In particolare, OFAT è sconsigliato a causa di inefficienze con risorse e interazioni mancanti. Possiamo vedere che questo approccio al testing ha gli stessi problemi. Tuttavia, se stiamo testando un software, possiamo riutilizzare questi casi di test in seguito, quindi creare questi test e determinare i risultati attesi non sono necessariamente sprechi di risorse di testing. Se troviamo un problema (ad esempio, il risultato non è quello previsto), sappiamo quale input è stato modificato e ha causato il problema. Ciò è particolarmente utile se fatto come parte di un processo di sviluppo di un'applicazione, in cui questi test possono essere eseguiti regolarmente (di nuovo, un argomento per un futuro blog).
Dove andiamo adesso?
Se leggete questo blog e vi chiedete perché non cambieremmo più di un input alla volta, state tranquilli, lo faremo. Infatti, i blog futuri discuteranno di come trattare questa sfida di test come un problema di progettazione di esperimenti. Restate sintonizzati!
Whittaker, JA, 2000. Che cosa è il test del software? E perché è così difficile?. IEEE software , 17 (1), pp.70-79.
