Ho bisogno di un test di unità se ho già un test di integrazione?

Hai esposto buoni argomenti a favore e contro i test unitari. Quindi devi chiederti, " Vedo valore negli argomenti positivi che superano i costi in quelli negativi? " Certamente lo faccio:

• Piccolo-e-veloce è un aspetto gradevole dei test unitari, sebbene non sia il più importante.
• Individuazione-bug [s] -easier è estremamente prezioso. Molti studi di sviluppo di software professionale hanno dimostrato che il costo di un bug aumenta rapidamente man mano che invecchiano e si sposta verso il basso nella pipeline di consegna del software.
• Trovare i bug mascherati è prezioso. Quando sai che un particolare componente ha verificato tutti i suoi comportamenti, puoi usarlo in modi che non è stato usato in precedenza, con sicurezza. Se l'unica verifica è tramite test di integrazione, sai solo che i suoi attuali usi si comportano correttamente.
• Il derisione è costoso nei casi reali, e il fatto di mantenere le prese in giro è doppiamente tale. In effetti, quando si prendono in giro oggetti o interfacce "interessanti", potrebbero anche essere necessari test per verificare che i propri oggetti finti modellano correttamente i propri oggetti reali!

Nel mio libro, i professionisti superano gli svantaggi.

Non vedo molto valore nel reimplementare un testcase di integrazione esistente come un unittest.

I test di integrazione sono spesso molto più facili da scrivere per applicazioni legacy non tdd perché solitamente le funzionalità da testare sono strettamente accoppiate, quindi le unità di test isolate (= non testate) possono essere difficoltose / costose / impossibili.

> Then what are the reasons to write/add unit tests?

A mio parere, lo sviluppo basato sui test è più efficace se si scrivono i test unitari prima del codice effettivo. In questo modo il codice che soddisfa i test diventa chiaramente separato con un minimo di riferimenti esterni che è facilmente testabile.

Se il codice esiste già senza i test delle unità, di solito è necessario molto lavoro extra per scrivere i test delle unità in seguito perché il codice non è stato scritto per un facile test.

Se fai TDD il codice automaticamente è facilmente testabile.

I test di integrazione dovrebbero solo verificare che diversi componenti stiano lavorando insieme come previsto. La correttezza o meno della logica dei singoli componenti dovrebbe essere verificata mediante test unitari.
La maggior parte dei metodi ha diversi possibili percorsi di esecuzione; pensa a if-then-else, alle variabili di input con valori sbagliati inaspettati o semplicemente sbagliati, ecc. Di solito gli sviluppatori tendono a pensare solo al percorso felice: il percorso normale che non va storto. Ma per quanto riguarda questi altri percorsi, hai due opzioni: puoi consentire al tuo utente finale di esplorare quei percorsi attraverso le azioni che eseguono nell'interfaccia utente e sperare che non blocchino la tua applicazione, oppure puoi scrivere test unitari che affermano il comportamento di questi altri percorsi e intraprendere azioni laddove necessario.

Alcuni dei motivi per cui hai indicato la tua domanda sono davvero importanti e di per sé potrebbero benissimo essere a favore del test unitario, ma YMMV. Ad esempio, quanto spesso esegui la tua suite di test integrata? La mia esperienza con i test integrati è che prima o poi diventeranno così lenti che non li eseguirai ogni volta che cambierai e il tempo tra l'inserimento e il rilevamento di un bug aumenterà.

Inoltre, un grosso errore che potresti fare è fidarsi di

Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.

non è importante. Ti aspetti che i tuoi utenti trovino i bug per te? La fiducia nelle coperture ottenute da test integrati è pericolosa, a mio avviso, si può facilmente ottenere un'alta percentuale di copertura, ma in realtà si sta testando molto poco.

Credo che il riferimento canonico contro i test integrati siano i post di JBrains:

link

nel caso in cui non li avessi già letti.

Infine, IMO il feedback che puoi ottenere dai test unitari per il tuo progetto è inestimabile. Giudicare un design per sentimento e affidarsi a test integrati può anche essere un errore.

Se ti aspetti di dover modificare o riorganizzare il tuo codice, è essenziale disporre di test unitari. I test unitari esistono non solo per dimostrare bug nel momento in cui il codice viene scritto, ma per mostrare quando vengono visualizzati nuovi bug quando viene scritto più codice.

Sì, è molto meglio scrivere prima i test di integrazione e unità, ma è molto utile averli anche se sono scritti in seguito.