A seconda di dove guardi, otterrai risposte leggermente diverse. Ho letto molto sull'argomento, ed ecco la mia distillazione; di nuovo, questi sono leggermente lanosi e altri potrebbero non essere d'accordo.
Test unitari
Verifica la più piccola unità di funzionalità, in genere un metodo / funzione (ad esempio, data una classe con uno stato particolare, la chiamata del metodo x sulla classe dovrebbe causare y). I test unitari dovrebbero essere focalizzati su una caratteristica particolare (ad esempio, chiamare il metodo pop quando lo stack è vuoto dovrebbe lanciare un InvalidOperationException). Tutto ciò che tocca dovrebbe essere fatto in memoria; ciò significa che il codice test e il codice testato non dovrebbero:
- Chiama in collaboratori (non banali)
- Accedi alla rete
- Hit un database
- Usa il file system
- Accendi un filo
- eccetera.
Qualsiasi tipo di dipendenza che è lenta / difficile da comprendere / inizializzare / manipolare dovrebbe essere cancellata / derisa / qualunque cosa usando le tecniche appropriate in modo da poter concentrarsi su ciò che l'unità di codice sta facendo, non su ciò che fanno le sue dipendenze.
In breve, i test unitari sono quanto più semplici possibili, facili da eseguire il debug, affidabili (a causa di fattori esterni ridotti), rapidi da eseguire e aiutano a dimostrare che i più piccoli elementi costitutivi del programma funzionano come previsto prima che vengano messi insieme. L'avvertenza è che, anche se puoi dimostrare che funzionano perfettamente in isolamento, le unità di codice possono esplodere quando combinate, il che ci porta a ...
Test di integrazione
I test di integrazione si basano su test unitari combinando le unità di codice e verificando che la combinazione risultante funzioni correttamente. Questo può essere sia l'interno di un sistema, sia la combinazione di più sistemi per fare qualcosa di utile. Inoltre, un'altra cosa che differenzia i test di integrazione dai test unitari è l'ambiente. I test di integrazione possono e utilizzano i thread, accedono al database o fanno tutto il necessario per garantire che tutto il codice e le diverse modifiche all'ambiente funzionino correttamente.
Se hai creato un codice di serializzazione e l'unità ha testato le sue parti interne senza toccare il disco, come fai a sapere che funzionerà durante il caricamento e il salvataggio su disco? Forse hai dimenticato di svuotare e gettare i filestream. Forse i tuoi permessi sui file non sono corretti e hai testato le viscere usando nei flussi di memoria. L'unico modo per scoprirlo con certezza è testarlo "davvero" utilizzando un ambiente più vicino alla produzione.
Il vantaggio principale è che troveranno bug che i test unitari non possono come ad esempio i bug di cablaggio (ad esempio un'istanza di classe A riceve inaspettatamente un'istanza nulla di B) e bug di ambiente (funziona bene sulla mia macchina a CPU singola, ma il mio la macchina a 4 core del collega non può superare i test). Lo svantaggio principale è che i test di integrazione toccano più codice, sono meno affidabili, i guasti sono più difficili da diagnosticare e i test sono più difficili da mantenere.
Inoltre, i test di integrazione non dimostrano necessariamente che funzioni complete. L'utente potrebbe non preoccuparsi dei dettagli interni dei miei programmi, ma lo faccio!
Test funzionali
I test funzionali verificano la correttezza di una particolare funzionalità confrontando i risultati per un determinato input con le specifiche. I test funzionali non riguardano se stessi con risultati intermedi o effetti collaterali, ma solo il risultato (a loro non importa che dopo aver fatto x, l'oggetto y abbia lo stato z). Sono scritti per testare parte delle specifiche, ad esempio "chiamando la funzione Square (x) con l'argomento 2 restituisce 4".
Test di accettazione
Il test di accettazione sembra essere diviso in due tipi:
Il test di accettazione standard prevede l'esecuzione di test su tutto il sistema (ad es. Utilizzo della pagina Web tramite un browser Web) per verificare se la funzionalità dell'applicazione soddisfa le specifiche. Ad esempio "facendo clic sull'icona di uno zoom si dovrebbe ingrandire la vista del documento del 25%". Non esiste un vero continuum di risultati, solo un risultato positivo o negativo.
Il vantaggio è che i test sono descritti in un inglese semplice e garantisce che il software, nel suo insieme, sia completo. Lo svantaggio è che hai spostato di un altro livello la piramide dei test. I test di accettazione toccano montagne di codice, quindi rintracciare un fallimento può essere complicato.
Inoltre, nello sviluppo agile del software, i test di accettazione dell'utente comportano la creazione di test per rispecchiare le storie degli utenti create da / per il cliente del software durante lo sviluppo. Se i test superano, significa che il software deve soddisfare i requisiti del cliente e le storie possono essere considerate complete. Una suite di test di accettazione è fondamentalmente una specifica eseguibile scritta in una lingua specifica del dominio che descrive i test nella lingua utilizzata dagli utenti del sistema.
Conclusione
Sono tutti complementari. A volte è vantaggioso concentrarsi su un tipo o evitarli del tutto. La differenza principale per me è che alcuni dei test guardano le cose dal punto di vista di un programmatore, mentre altri usano un focus cliente / utente finale.