La versione estremamente breve: test più piccoli, poiché eseguono parti più piccole del sistema, limitano naturalmente ciò che i programmatori possono scrivere, e quindi questo crea un'opportunità per un feedback più nitido (più facile da notare / più difficile da ignorare). Consentitemi di aggiungere che ciò non porta necessariamente a una progettazione migliore, ma piuttosto crea l'opportunità di notare prima i rischi di progettazione.
In primo luogo, per chiarire, quando dico "microtest" intendo "un piccolo test" e niente di più. Uso questo termine perché non intendo "unit test": non voglio essere coinvolto in dibattiti su ciò che costituisce una "unità". Non mi interessa (almeno non qui / ora). Due persone probabilmente si accorderanno più facilmente su "piccole" di quanto non farebbero su "unità", così ho gradualmente deciso di adottare "microtest" come termine standard emergente per questa idea.
Test più grandi, ovvero test che eseguono parti più grandi del sistema nella loro parte "azione", tendono a non criticare il progetto in modo chiaro né completo come i test più piccoli. Immagina l'insieme di tutte le basi di codice che potrebbero superare un determinato gruppo di test, il che significa che potrei riorganizzare il codice e passerebbe comunque quei test. Per test più grandi, questo set è più grande; per test più piccoli, questo set è più piccolo. Detto in altro modo, i test più piccoli limitano maggiormente il progetto, 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 ha bisogno di sentire, e che ti urla per trasmettere urgenza in modo che le altre persone potrebbero non sentirsi a proprio agio facendo. I test integrati, d'altra parte, mantengono il silenzio e accennano ai problemi solo quando non hai più tempo né energia per affrontarli. I test integrati rendono troppo facile eliminare i problemi di progettazione sotto il tappeto.
Con test più grandi (come i test integrati), i programmatori tendono principalmente a mettersi nei guai attraverso la sciattezza: hanno abbastanza libertà di scrivere codice aggrovigliato che in qualche modo supera i test, ma la loro comprensione di quel codice svanisce rapidamente nel momento in cui passano all'attività successiva e altri hanno indebita difficoltà a leggere il design 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 a causa di specifiche eccessive: vincolano eccessivamente i test aggiungendo dettagli irrilevanti, di solito copiando / incollando dal test precedente, e così facendo si dipingono relativamente rapidamente in un angolo. Buone notizie: Trovo molto più semplice e sicuro rimuovere i dettagli estranei dai test dopo diverse ore o giorni dopo averli scritti di quanti ne trovo per separare il codice di produzione aggrovigliato mesi o anni dopo averlo scritto. Man mano che gli errori vanno, l'eccessiva specificazione fa più rapidamente danni sempre più evidenti e il programmatore di allerta vede in precedenza che devono riparare le cose. Lo considero un punto di forza: noto prima i problemi e li risolvo prima che tali problemi strozzassero la nostra capacità di aggiungere funzionalità.