Se testiamo una funzione B, testando una funzione C che chiama quella funzione B, cioè scrivendo un programma di test per testare la funzione C che chiama quella funzione B, il metodo di test è ancora chiamato unit test o qualcos'altro?
Quando si preferisce testare indirettamente una funzione che chiama la funzione target e quando si preferisce testare direttamente una funzione?
Risposte:
Una definizione popolare di unit test è quella dell'ISTQB:
Un unit test è la parte più piccola testabile di un'applicazione come funzioni, classi, procedure, interfacce. Il test unitario è un metodo mediante il quale vengono testate singole unità del codice sorgente per determinare se sono idonee all'uso.
Secondo questa definizione:
Ora può esserci una differenza tra intento e ambito del test. Se scrivi un programma di test per B usando C, è comunque un test unitario di C, perché tutto ciò che puoi fare è fornire l'input a C e controllare in base all'output se B era corretto. È solo che deduci che B funziona perché C funziona.
Esiste anche una definizione di test di integrazione :
Test eseguiti per esporre difetti nelle interfacce e nelle interazioni tra componenti o sistemi integrati.
La consueta definizione di componenti software implica che è indipendente e può essere implementato da solo. Qui, B e C sembrano non essere componenti indipendenti, quindi non abbiamo test di integrazione.
Questo dipende molto da ciò che consideri un'unità. Se Cè così semplice che testarlo separatamente non ha senso, allora il tuo test è un test unitario.
Molto più importante è che la tua suite di test unitari per una determinata unità abbia una copertura di linea vicina al 100% e testi tutti i percorsi di codice praticamente previsti.
Sì, lo chiamiamo ancora unit-test se le funzioni chiamano altre funzioni.
I test unitari dovrebbero testare il comportamento pubblico di una classe e non le implementazioni private. Come suggerito da questo test di Google sull'articolo del gabinetto .
Se segui le regole di Clean Code, le tue funzioni non dovrebbero essere più lunghe di 4 righe di codice. Ciò rende impossibile non testare un'altra funzione privata con i test unitari.
Perché non dovresti provare unitamente la maggior parte delle funzioni private separatamente? Perché il refactoring ti costringerebbe ad aggiornare continuamente tutti i test unitari di implementazione. Ciò diventerà frustrante quando ne avrai molti, mentre il comportamento pubblico non dovrebbe cambiare durante il refactoring e quindi il test non dovrebbe richiedere alcun aggiornamento. Dovresti essere in grado di testare i privati con il loro genitore pubblico. A volte potrebbe valere la pena testare privati complessi, ma ti chiedi se dovrebbero essere una classe separata per conto proprio?
Test di integrazione :
Ora se la funzione fa parte di un'altra classe è diversa. Quindi lo chiameremmo test dei componenti o test di integrazione. Stai integrando più classi e stai eseguendo un test contro di esse. La funzione B dipende dalla funzione C. Per essere in grado di testare la funzione B è possibile utilizzare l' iniezione di dipendenza per isolare la funzione che si sta testando, ora sarebbe di nuovo un test unitario.