Dove devo tracciare la linea tra unit test e test di integrazione? Dovrebbero essere separati?

Ho un piccolo framework MVC su cui sto lavorando. La sua base di codice sicuramente non è grande, ma non è più solo un paio di classi. Alla fine ho deciso di fare il grande passo e iniziare a scrivere test per questo (sì, lo so che avrei dovuto farlo da sempre, ma finora l'API era super instabile)

Ad ogni modo, il mio piano è di rendere estremamente facile il test, compresi i test di integrazione. Un esempio di test di integrazione farebbe qualcosa del genere:

Oggetto richiesta HTTP falso -> framework MVC -> oggetto risposta HTTP -> verifica che la risposta sia corretta

Poiché tutto ciò è fattibile senza alcuno stato o strumenti speciali (automazione del browser, ecc.), In realtà potrei farlo facilmente con i normali framework di unit test (utilizzo NUnit).

Ora la grande domanda. Dove devo esattamente tracciare il confine tra unit test e test di integrazione? Dovrei testare solo una classe alla volta (il più possibile) con i test unitari? Inoltre, i test di integrazione devono essere inseriti nello stesso progetto di test del mio progetto di test unitario?

Integrazione vs. unit test

È necessario mantenere i test unitari e i test di integrazione completamente separati. I test unitari dovrebbero testare una cosa e una sola cosa e in completo isolamento del resto del sistema. Un'unità è definita in modo approssimativo ma di solito si riduce a un metodo o una funzione.

Ha senso avere dei test per ogni unità in modo da sapere che i loro algoritmi sono implementati correttamente e si sa immediatamente cosa è andato storto dove, se l'implementazione è difettosa.

Dal momento che si esegue il test in completo isolamento durante il test unitario, si utilizzano stub e oggetti finti per comportarsi come il resto dell'applicazione. È qui che entrano in gioco i test di integrazione. Testare tutte le unità in isolamento è fantastico, ma è necessario sapere se le unità funzionano effettivamente insieme.

Ciò significa sapere se un modello è effettivamente archiviato in un database o se viene effettivamente emesso un avviso dopo il fallimento dell'algoritmo X.

Sviluppo guidato da test

Facendo un passo indietro e guardando Test Driven Development (TDD) ci sono diverse cose da prendere in considerazione.

1. Scrivi il test unitario prima di scrivere effettivamente il codice che lo fa passare.
2. Fai il superamento del test, scrivi il codice sufficiente per farlo.
3. Ora che il test ha superato è tempo di fare un passo indietro. C'è qualcosa da refactoring con questa nuova funzionalità in atto? Puoi farlo in modo sicuro poiché tutto è coperto da test.

Integrazione prima vs integrazione per ultima

I test di integrazione si adattano a questo ciclo TDD in due modi. Conosco persone a cui piace scriverle in anticipo. Chiamano un test di integrazione un test end-to-end e definiscono un test end-to-end come un test che testa completamente l'intero percorso di un caso d'uso (pensa a impostare un'applicazione, avviarlo, andare su un controller, eseguirlo, verifica del risultato, dell'output, ecc ...). Quindi iniziano con il loro primo test unitario, lo fanno passare, aggiungono un secondo, lo fanno passare, ecc ... Lentamente sempre più parti del test di integrazione passano pure fino al completamento della funzione.

L'altro stile sta costruendo un test unitario per test unitario e aggiungendo successivamente i test di integrazione ritenuti necessari. La grande differenza tra questi due è che nel caso del test di integrazione prima sei costretto a pensare alla progettazione di un'applicazione. Questo tipo di disaccordo con la premessa che TDD riguarda la progettazione delle applicazioni tanto quanto i test.

Aspetti pratici

Nel mio lavoro abbiamo tutti i nostri test nello stesso progetto. Vi sono tuttavia gruppi diversi. Lo strumento di integrazione continua esegue prima quelli che sono contrassegnati come test unitari. Solo se quelli hanno successo vengono eseguiti anche i test di integrazione più lenti (perché fanno richieste reali, usano database reali, ecc.).

Ad ogni modo usiamo un file di prova per una classe.

Lettura consigliata

1. Software orientato agli oggetti in crescita, guidato da test Questo libro è un ottimo esempio della prima metodologia del test di integrazione
2. L'arte dei test unitari, con esempi in dot.net Su test unitari, con esempi in dot.net: D Ottimo libro sui principi alla base dei test unitari.
3. Robert C. Martin su TDD (articoli gratuiti): leggi anche i primi due articoli che ha collegato lì.

Ciò che è importante in qualsiasi strategia di test è la copertura del test, ovvero la capacità di dimostrare che tutte le funzionalità sono in fase di test.

In generale, e se non si hanno requisiti specifici contrari (ad es. DO178 livello A, IEC61508 SIL 4 ecc.) Che non sembrano essere il caso nella propria situazione, quindi se è possibile verificare la piena funzionalità della classe o di un modulo (e dimostrare di averlo) a livello di sistema, quindi i test a livello di sistema sono adeguati. E così via. Il test unitario è necessario solo quando non hai esaminato ulteriormente il test.

Dove devo esattamente tracciare il confine tra unit test e test di integrazione?

Dato che il test di intergrazione è di solito più semplice, rapido ed economico, traccia la linea il più lontano possibile ...

Dovrei testare solo una classe alla volta (il più possibile) con i test unitari?

Dipende dall'ambito, di nuovo ... per definizione, un test unitario sta testando una singola unità. Ma se riesci a testare completamente un modulo completo in una volta, allora se lo desideri, fallo. Stai effettivamente eseguendo diversi test unitari in un colpo.

Inoltre, i test di integrazione devono essere inseriti nello stesso progetto di test del mio progetto di test unitario?

Nessun motivo fondamentale perché no ... a meno che il test di livello superiore non sia eseguito da un tester indipendente, a quel punto dovresti emettere solo una strumentazione eseguibile e minima.

Quando ho piccoli progetti inserisco tutti i test nello stesso progetto. Dal momento che un progetto più grande avrebbe queste divisioni, mi assicuro solo che sarebbe possibile stuzzicarle se fosse necessario.

Con i test unitari di solito collaudo solo una classe (SUT) in un file.