È pericoloso sostituire i test unitari per il test dell'utente? [chiuso]

I test manuali e i test unitari sono progettati per scopi diversi ^* , quindi la risposta è "sì" - sostituire l'uno con l'altro è una pratica pericolosa.

Le unit test stabiliscono le tue ipotesi sul tuo codice sotto forma di asserzioni che fai durante i tuoi test. Insieme ai test di integrazione automatizzati, i test unitari contribuiscono a garantire che il software esegua ciò che si ritiene debba fare. Se fatti correttamente, dovrebbero darti un alto livello di sicurezza nella correttezza del tuo software. I test automatici non richiedono molto tempo e sono meno soggetti a errori.

Tuttavia, spesso non è pratico eliminare tutti i test manuali. Le aree specifiche di interesse includono l'integrazione con altri prodotti che è necessario utilizzare, come installatori, browser Web e sistemi operativi. Come minimo, qualcuno deve installare il prodotto prima della spedizione e vedere se si avvia o aprire il tuo prodotto nel browser per vedere se la grafica rimane nei posti giusti. Tutto ciò può essere automatizzato, ma lo sforzo per realizzarlo non ne vale la pena, soprattutto perché stiamo parlando di una lista di controllo di dieci minuti.

Se parliamo della distinzione specifica "test manuale vs. test unitario", i due concetti non affettano lo spazio del test del software nella stessa dimensione: oltre ai test unitari, sono necessari test di integrazione, test di regressione, e prove di stress. Questi sono solitamente automatizzati, ma possono essere fatti manualmente. Inoltre, anche il collaudo dell'unità può essere eseguito manualmente con un piccolo aiuto di un driver software. Ecco perché sostituire l'uno con l'altro non è un buon paragone: se i test manuali riguardano test di unità, test di regressione, test di stress e test di integrazione, sostituirli con test di unità automatizzate non è uno scambio equo. Se il divario è colmato con altri media di test automatici, allora è possibile spostare un po 'di peso dal test manuale al test unitario, ma non si riuscirebbe a eliminare completamente il test manuale.

I test unitari automatizzati rispondono alla domanda "Fa quello che pensavo di aver chiesto?" mentre il test manuale risponde alla domanda "Fa qualcosa che sembra ragionevole per un utente?".

Domande diverse. E se sostituisci i metodi per testare l'uno per l'altro, tenderai a ottenere risultati non ottimali.

Quando dici "Test manuale", io intendo che intendi un intero sistema / programma? Se è così, questo non è lo stesso di test unitario ed è più simile al test dell'utente. I test unitari (dovrebbero) mirano a un pezzo di codice molto specifico (un metodo / proprietà su una classe) e lo testano in isolamento. I test unitari sono anche test scritti da sviluppatori per sviluppatori. I test manuali (presumo che intendiate test basati sull'utente) sono per gli utenti del sistema spesso eseguiti (se fortunati) dai tester per il proprietario / sponsor del prodotto. Dovresti finire con un numero molto maggiore di test unitari rispetto ai test utente perché stanno testando un livello più piccolo di scenario. Quindi, direi di sì, è pericoloso sostituire i test di unità per i test manuali, perché così facendo probabilmente finirai per testare cose meno specifiche che potrebbero far passare più bug.

Vale anche la pena notare che i test unitari sono rapidi. Hai il tempo di eseguire migliaia di test manuali ogni volta che apporti modifiche al codice?

I test unitari sono importanti, non il tutto e il fine del test. Lo scopo principale non è quello di trovare bug durante la scrittura e l'esecuzione del test, ma di evidenziare quando i cambiamenti del comportamento attesi in futuro (e conseguentemente i bug di regressione).

Certamente non hanno lo stesso scopo che prova con gli utenti.