Come e quando utilizzare UNIT test correttamente

L'idea del collaudo di unità è di consentire lo sviluppo di codice completamente modulare. Probabilmente già sai che il codice modulare è la strada da percorrere, in quanto incoraggia i disegni riutilizzabili e chiaramente mirati.

Se si tenta di testare un intero sistema nel suo complesso, allora molte parti diverse hanno la possibilità di fallire. In qualsiasi sistema di dimensioni ragionevoli, sarebbe quasi impossibile tenere conto di ogni possibile problema. Inoltre, quando vengono rilevati problemi, potrebbe essere difficile (o quasi impossibile) individuare il codice responsabile.

Tuttavia, se porzioni diverse del codice sono completamente separate da altre parti (ad esempio, non dipendono l'una dall'altra), è possibile utilizzare il test dell'unità per verificare un sottoinsieme del sistema più grande. È molto più facile rilevare i bug in una piccola quantità di codice, piuttosto che in grandi quantità.

Nell'esempio che hai presentato, ci sono due super-porzioni del tuo codice: la parte che recupera i dati da un database; e la parte che elabora tali dati. Se si è tentato di testare i due insieme, il test potrebbe essere crivellato di errori a causa del tentativo di accesso al database. Esistono numerose reti e altri problemi di I / O che potrebbero emergere durante la lettura del database. Soprattutto in casi estremi, questo può rendere molto difficile testare la porzione di elaborazione del codice. Allo stesso modo, potrebbero esserci dei bug nel codice di elaborazione che, per qualche motivo, non sono chiaramente localizzati all'interno di quella parte del codice.

La soluzione è usare il test dell'unità. Invece di testare il recupero e l'elaborazione di insieme , li separi. È possibile alimentare tutti i dati che si desidera alla parte di elaborazione per vedere se funziona correttamente. Se qualcosa va storto, si sa che il problema è un problema di elaborazione e non relativo alla lettura del database. Allo stesso modo, è possibile eseguire semplici test per garantire che si stia tentando di accedere a quel database in modo corretto. Eventuali problemi che si presentano in questo momento sono sicuramente correlati alla lettura del database.

Quindi il testing delle unità è davvero inestimabile nel test del codice per la robustezza. Inoltre, incoraggia un modello di progettazione che è molto incoraggiante. Nello specifico, gli sviluppatori che utilizzano i test unitari devono progettare in modo tale che il loro codice possa essere separato in unità modulari. Ad esempio, una funzione che si basa pesantemente sullo stato mutabile globale è intrinsecamente meno testabile in unità di una funzione che si basa solo su argomenti per produrre un risultato.

Modifica

Una cosa che ho dimenticato di menzionare è che i test unitari non sono un ripensamento. Sono concepiti per essere parte integrante del processo di sviluppo, in modo che le piccole parti di codice siano garantite come robuste. Ciò aumenta la robustezza del codice durante lo sviluppo. Come ogni nuova porzione è scritta, può essere immediatamente testata dall'unità per scoprire potenziali difetti. Pertanto, vengono poste solide fondamenta su quali livelli di codice robusto possono essere scritti. Il risultato finale è che un prodotto finale ha più probabilità di avere un livello di correzione molto più alto di un prodotto equivalente che viene testato dopo il processo di sviluppo. Inoltre, il tempo impiegato per i test è generalmente ridotto.

Il test unitario consente di testare moduli di codice senza l'applicazione. È possibile testare il codice prima che l'applicazione esista. Nello sviluppo orientato agli oggetti, i test unitari dovrebbero testare solo una classe. I test di integrazione sono utilizzati per verificare che più classi lavorino in concerto. Fortunatamente, molti test di integrazione possono essere eseguiti utilizzando framework di test unitari. L'unità di test di singole classi può essere difficile in quanto potrebbe essere necessario fornire oggetti fittizi per soddisfare le loro dipendenze. Questo è particolarmente vero quando si verifica il codice relativo al database. In molti casi, il tuo esempio potrebbe essere un test di integrazione.

Supponendo che l'unità e / o l'integrazione abbiano testato il codice che prende il pacchetto e lo elabora nel database, si rende più semplice testare l'applicazione. Ora se l'applicazione non riesce a elaborare i dati nel database, è probabile che il problema si verifichi prima del codice che carica effettivamente i dati nel database. Forse il pacchetto non viene preparato correttamente o inviato al gestore corretto.

Più codice hai che è stato testato per unità e / o integrazione, più è semplice testare l'intera applicazione in quanto dovresti avere molte parti che sono già testate e che possono essere considerate affidabili per funzionare correttamente.

I test di unità e integrazione semplificano i test in quanto gli sviluppatori oi sistemi di build possono testare il codice prima che l'applicazione sia completa. Test simili sono fatti quando si costruiscono cose come aerei e automobili. Tutto da viti su fino sono testati per garantire che siano all'altezza del lavoro; quindi vengono testati gli assemblaggi; e infine il prodotto completato viene testato. In questo modo è più facile sostituire le parti quando necessario, poiché i test possono essere applicati alla parte sostitutiva. Quando applichiamo queste tecniche, unità, integrazione e test delle applicazioni, generalmente otteniamo software più affidabile e gestibile.

Quando viene rilevato un problema con il codice che viene testato unitamente o integralmente, è comune aggiungere un nuovo caso di test per verificare che il problema sia risolto. Ciò aumenta la robustezza della suite di test nel tempo.

I sistemi di build automatici eseguono spesso i test di unità e di integrazione come parte del processo di compilazione. Ciò consente al sistema di generazione di contrassegnare o rifiutare il codice che non supera più le suite di test. I test delle applicazioni possono quindi concentrarsi sulla verifica della funzionalità aziendale e dell'usabilità senza preoccuparsi troppo della funzionalità del codice.

EDIT: mi sono reso conto che non avevo risposto al titolo di questa domanda.

Quando utilizzare utilizzare il test UNIT: utilizzare il test dell'unità per testare l'interfaccia pubblica alle classi o ai moduli. Puoi scegliere di non testare il codice banale. In generale, i metodi privati non sono testati. Più il codice è complesso, più è importante sviluppare test unitari.

Come test unitario: utilizzare un framework di test, ad esempio jUnit (il framework è stato sviluppato per molte lingue e in un gruppo si parla di xUnit). Sviluppa una serie di input come output attesi. Concentrarsi su casi limite e casi limite. Aggiungi test che gestiranno casi comuni non ancora coperti. Utilizzare queste aspettative per scrivere casi di test che verificano che gli input dati forniscano i risultati attesi. Non dimenticare di testare le condizioni di errore.

Nei test unitari scrivi prima i test, poi implementa il codice.