In che modo i test di integrazione criticano il design?

I microtest possono aiuta a creare un buon design . Scrivendo buoni piccoli test, stai deliberatamente testando una piccola quantità di codice e riempiendo le sue lacune con oggetti fittizi . Questo porta ad un basso accoppiamento (le cose non sono dipendenti l'una dall'altra) e ad alta coesione (le cose che appartengono insieme rimangono insieme). In questo modo, quando torni indietro e apporti le modifiche, è facile trovare ciò che è responsabile di ciò che stai cercando e meno probabilità di rompere le cose nel fare la modifica. Questo non risolverà tutti i tuoi progetti ma può aiutarti.

In questo contesto, J.B. Rainsberger nota che se stai facendo fatica a scrivere un test unitario, probabilmente hai un problema con il tuo design che sta causando la difficoltà, e quindi i test stanno criticando implicitamente il design. Egli ritiene che sia una buona cosa, perché senza i piccoli test è possibile mantenere la propria architettura in linea è facile allontanarsi dai buoni schemi di progettazione, che i test integrati non cattureranno.

Aggiornamento : come annotato da Rainsberger in basso, non intendeva che i microtest fossero sinonimi dei test unitari. Ha anche fornito una risposta dettagliata che può darti una visione più approfondita di ciò che stava comunicando.

La versione estremamente corta: test più piccoli, perché eseguono parti più piccole del sistema, vincolando naturalmente ciò che i programmatori possono scrivere, e questo crea un'opportunità per un feedback più nitido (più facile da notare / più difficile da ignorare). Lasciatemi aggiungere che questo non porta necessariamente a una progettazione migliore, ma piuttosto crea l'opportunità di notare i rischi di progettazione prima possibile.

In primo luogo, per chiarire, quando dico "microtest" intendo "un piccolo test" e nient'altro. Uso questo termine perché non intendo "test unitario": non voglio essere coinvolto nei dibattiti su ciò che costituisce una "unità". Non mi interessa (almeno non qui / ora). Probabilmente due persone concorderanno più facilmente su "piccolo" rispetto a "unità", quindi ho gradualmente deciso di adottare "microtest" come termine standard emergente per questa idea.

I test più grandi, ovvero i test che eseguono parti più grandi del sistema nella loro parte "azione", tendono a non criticare il progetto in modo altrettanto chiaro né completamente come test più piccoli. Immaginate l'insieme di tutte le basi di codice che potrebbero passare un determinato gruppo di test, il che significa che potrei riorganizzare il codice e passare comunque quei test. Per test più grandi, questo set è più grande; per test più piccoli, questo set è più piccolo. Detto in modo diverso, test più piccoli vincolano maggiormente il design, quindi un numero inferiore di progetti può farli passare. In questo modo, i microtest possono criticare maggiormente il design.

Dico "più duramente" per evocare l'immagine di un amico che ti dice direttamente ciò che non vuoi sentire, ma devi sentire, e chi ti urla di trasmettere l'urgenza in un modo che altre persone potrebbero non sentirsi a proprio agio nel farlo. I test integrati, d'altra parte, rimangono tranquilli e suggeriscono solo i problemi soprattutto quando non si ha più tempo né energia per affrontarli. I test integrati rendono troppo facile spazzare i problemi di progettazione sotto il tappeto.

Con test più grandi (come test integrati), i programmatori tendono principalmente a mettersi nei guai attraverso la sciatteria: hanno abbastanza libertà di scrivere codice intricato che in qualche modo supera i test, ma la loro comprensione di quel codice svanisce rapidamente nel momento in cui passano a il prossimo compito, e altri hanno indebita difficoltà a leggere il disegno aggrovigliato. Qui sta il rischio di affidarsi a test integrati. Con test più piccoli (come i microtest), i programmatori tendono principalmente a mettersi nei guai attraverso la sovra-specifica: vincolano eccessivamente i test aggiungendo dettagli irrilevanti, di solito copia / incolla dal test precedente, e così facendo si dipingono in modo relativamente rapido in un angolo. Buone notizie: trovo molto più facile e sicuro rimuovere i dettagli estranei dai test parecchie ore o giorni dopo che li ho scritti di quanto non riesca a separare il codice di produzione aggrovigliato mesi dopo anni di scrittura. A mano a mano che gli errori vanno, la sovra-specificazione fa sempre più danni evidenti, e il programmatore di allerta vede prima che hanno bisogno di sistemare le cose. Considero questo un punto di forza: ho notato problemi in precedenza e li ho sistemati prima che questi problemi strozzassero la nostra capacità di aggiungere funzionalità.

Significa che una buona progettazione del software è meglio informata dai test unitari rispetto ai test di integrazione.

Ecco perché. I test delle unità di scrittura ti obbligano a scrivere codice testabile dall'unità. Il codice unitamente testabile tende ad essere un design migliore del codice che non ha test unitari.

I test di integrazione non informano il tuo codice nello stesso modo perché stai solo testando il livello esterno del tuo software, non le interfacce interne che collegano il tuo software insieme.