Test gap tra unità e integrazione: integrazione nei test di integrazione di unità piccole, componenti, unità

Question

Test gap tra unità e integrazione: integrazione nei test di integrazione di unità piccole, componenti, unità

#1 da (6 voti)

9

Nelle ultime settimane ho rimuginato e studiato come colmare una lacuna nella nostra metodologia di test. In termini semplificati, i test unitari sono troppo piccoli e i test di integrazione tradizionali sono troppo grandi.

Si presenta uno scenario frequente in cui A e B utilizzano entrambi componente C . Tuttavia A e B hanno requisiti leggermente diversi per, e fanno ipotesi leggermente diverse su C . Se sono lo sviluppatore di A come e dove collaudo le mie ipotesi su C ?

Ovviamente il test unitario A con ipotesi assurde su C va bene per testare A in isolamento, ma non prova le ipotesi stesse.

Un'altra possibilità è aggiungere test unitari per C . Tuttavia questo non è l'ideale perché, mentre A è in sviluppo, l'alterazione dei test per C con ipotesi in evoluzione da A sarà eccessivamente maldestra. Infatti, lo sviluppatore di A s potrebbe non avere nemmeno un accesso adeguato ai test unitari di C (ad esempio una libreria esterna).

Per inquadrare questo con un esempio più concreto: supponi che questa sia un'applicazione di nodo. A e B dipendono da C per leggere un file (tra le altre cose) e memorizzare il contenuto del file in oggetto passato a C . All'inizio tutti i file che C gestisce sono piccoli e possono essere letti in modo sincrono senza blocchi significativi. Tuttavia lo sviluppatore di B si rende conto che i suoi file stanno diventando enormi e ha bisogno di cambiare C in una lettura asincrona. Ciò si traduce in un errore di sincronizzazione sporadica in A , che presuppone ancora che C stia leggendo i file in modo sincrono.

Questo è il tipo di bug che è notoriamente difficile da rintracciare dai test di integrazione completi e che potrebbe non essere affatto coinvolto nei test di integrazione. Inoltre, non viene rilevato dai test unitari di A s perché le ipotesi di A s vengono prese in giro. Tuttavia potrebbe facilmente essere catturato da un test di integrazione "mini" che esercita solo A e C .

Ho trovato solo alcuni riferimenti a questo tipo di test. Integrazione nel Piccolo , Component Integration Testing , Integrazione unità Test. Si riferisce anche a test BDD piuttosto che a un test formale dell'unità TDD.

Come posso colmare questo vuoto di test? Specificamente - dove metto tali test? Come faccio a simulare gli input di A e C per i test di integrazione "mini"? E quanto sforzo dovrebbe essere messo nel separare le preoccupazioni dei test tra questi test e i test unitari? O c'è un modo migliore per riempire il vuoto test?

bdd testing unit-testing integration-tests node.js

posta mjhm 06.07.2014 - 19:03

fonte

1 risposta

Leggi altre domande sui tag bdd testing unit-testing integration-tests node.js

L'individuazione degli eventi è valida solo quando le scritture sono rare? Quanto è praticabile "Windows Workflow Foundation"? Quali alternative dovrei prendere in considerazione? [chiuso]

score 6 · Answer 1

Mi sembra che tu abbia un problema fondamentale con i tuoi componenti.

C dovrebbe fare ciò che C ha bisogno di fare, ed essere testato, documentato e progettato per fare proprio questo. Quando hai una situazione in cui C è progettato per "fare ciò che B vuole" hai una relazione violenta, una che diventa molto chiara quando A arriva e vuole che C faccia qualcosa di leggermente diverso.

Ciò che non dovresti fare è il test unitario C nel contesto di A, e specialmente non A nel contesto di C - testerai A in modo indipendente e fornirai i risultati di una C derisa a A. Se il reale la versione mondiale di C non fornisce quegli stessi risultati, quindi si ha un errore di progettazione o difetto in C che verrà catturato quando si eseguono i test di integrazione di grandi dimensioni. Il test delle unità è sempre stato così: non è possibile testare una unità testando un'altra unità allo stesso tempo. Il test delle unità non è progettato per farlo.

I test di integrazione non devono essere "l'intero programma", anche se spesso sono impostati in questo modo. Possono essere un banco di prova che esegue A e C insieme senza eseguire il resto del programma (o il meno possibile). A questo punto non posso fornire ulteriori consigli in quanto dipende da cosa fanno questi componenti e come interagiscono con il resto del programma, ma di solito è possibile scrivere un banco di prova che fornisce una copertura di prova di entrambi i componenti. Se vale la pena di farlo, o se sia più efficiente testare l'integrazione dell'intero programma come uno (anche se si esegue un sottoinsieme dei test di integrazione) è qualcosa a cui solo tu puoi rispondere. La maggior parte dei test di integrazione comprende molte sezioni, quindi spero che dovresti essere in grado di eseguire solo quelle rilevanti per questi 2 componenti (e in caso contrario, ottenere la suite di test di integrazione in modo che funzioni in molti pezzi).