Verifica del divario tra unità e integrazione: integrazione nei test di integrazione di piccole dimensioni, componenti e unità

Nelle ultime settimane ho riflettuto e ricercato 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.

Uno scenario frequente viene su dove Ae Bcomponente sia l'uso C. Tuttavia Ae Bavere requisiti leggermente diversi per, e fare un po 'diverse ipotesi circa C. Se sono lo sviluppatore di Acome e dove testare i miei presupposti C?

Ovviamente i test unitari Acon ipotesi beffarde vanno Cbene per i test Ain isolamento, ma non verificano gli stessi presupposti.

Un'altra possibilità è aggiungere test unitari per C. Tuttavia questo non è l'ideale perché, mentre Aè in fase di sviluppo, alterare i test Ccon ipotesi in evoluzione da Asarà eccessivamente goffo. In effetti A, lo sviluppatore potrebbe non avere nemmeno un accesso adeguato ai test unitari C(ad esempio una libreria esterna).

Per inquadrare questo con un esempio più concreto: supponiamo che si tratti di un'applicazione nodo. Ae Bdipende dalla Clettura di un file (tra le altre cose) e dalla memorizzazione del contenuto del file nell'oggetto passato a C. Inizialmente tutti i file che Cgestiscono sono piccoli e possono essere letti in modo sincrono senza blocchi significativi. Tuttavia, lo sviluppatore si Brende conto che i suoi file stanno diventando enormi e deve passare Ca una lettura asincrona. Ciò si traduce in un bug di sincronizzazione sporadico A, che sta ancora assumendo la Clettura dei file in modo sincrono.

Questo è il tipo di bug notoriamente difficile da rintracciare dai test di integrazione completi e potrebbe non essere individuato affatto nei test di integrazione. Inoltre, non viene colto dai Atest unitari perché le Aassunzioni di s sono derise. Tuttavia potrebbe essere facilmente catturato da un "mini" test di integrazione che esercita solo Ae C.

Ho trovato solo alcuni riferimenti a questo tipo di test. Integrazione nel piccolo , Test di integrazione dei componenti , Test di integrazione delle unità . Si riferisce anche in qualche modo alla direzione del test BDD piuttosto che al test formale dell'unità TDD.

Come posso colmare questa lacuna di prova? In particolare, dove posso mettere tali test? Come faccio a deridere gli input di Ae Cper i "mini" test di integrazione? E quanti sforzi dovrebbero essere fatti per separare le preoccupazioni dei test tra questi test e test unitari? O c'è un modo migliore per colmare il gap di test?

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

C dovrebbe fare ciò che deve 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 offensiva, che diventa molto chiara quando arriva A e vuole che C faccia qualcosa di leggermente diverso.

Quello che non dovresti fare è test unitario C nel contesto di A, e soprattutto non A nel contesto di C - testerai A in modo indipendente e fornirai i risultati di una C derisa ad A. Se la versione reale di C non fornisce gli stessi risultati, quindi hai un bug o un difetto di progettazione in C che verrà colto quando esegui i tuoi grandi test di integrazione. Il test unitario è sempre stato così: non è possibile testare un'unità testando un'altra unità contemporaneamente. Il test unitario non è progettato per farlo.

I test di integrazione non devono essere "l'intero programma", sebbene spesso siano 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 consigliare ulteriormente in quanto dipende da cosa fanno questi componenti e da come interagiscono con il resto del programma, ma di solito è possibile scrivere un banco di prova che fornisce la copertura di prova di entrambi i componenti. Se vale la pena fare questo o se è più efficiente test di 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 sono composti da molte sezioni, quindi spero che tu possa essere in grado di eseguire solo quelli pertinenti a questi 2 componenti (e, in caso contrario,