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?
Una definizione popolare di unit test è quella di ISTQB:
A unit test is the smallest testable part of an application like functions, classes, procedures, interfaces. Unit testing is a method by which individual units of source code are tested to determine if they are fit for use.
Secondo questa definizione:
Ora può esserci una differenza tra l'intento e l'ambito del test. Se si scrive un programma di test per B usando C, è ancora un test unitario di C, perché tutto ciò che si può fare è fornire l'input a C e verificare 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 :
Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.
La normale definizione di componenti software implica che sia 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 quello che consideri un'unità. Se C è così semplice che testarlo separatamente non ha senso, il test è un test unitario.
Molto più importante è per la suite dei test unitari di una determinata unità per avere una copertura della linea vicina al 100% e per testare tutti i percorsi di codice praticamente attesi.
Sì, lo chiamiamo ancora un test di unità 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 da toilette .
Se segui le regole di Pulisci codice allora le tue funzioni non dovrebbero essere più lunghe di 4 righe di codice. Ciò rende impossibile non testare un'altra funzione privata con i tuoi test unitari.
Perché non dovresti testare separatamente la maggior parte delle funzioni private separatamente? Poiché il refactoring ti costringerebbe a continuare ad aggiornare tutti i test delle unità di implementazione. Questo diventerà frustrante quando ne hai 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 di testare i privati complessi, ma chiedersi se dovrebbero essere una classe separata per conto proprio?
Test di integrazione :
Ora se la funzione fa parte di un'altra classe è diversa. Quindi chiameremo test dei componenti o test di integrazione. Stai integrando più classi e eseguendo un test contro di loro. La funzione B dipenderebbe dalla funzione C. Per essere in grado di testare unitamente la funzione B, potresti usare iniezione dipendenza per isolare la funzione che stai testando, ora sarebbe di nuovo un test unitario.
Leggi altre domande sui tag testing unit-testing