Unit test e TDD quando il codice deve crescere senza rompere quello che funziona

Il testing non è un costo: è un moltiplicatore di velocità

Il testing viene percepito come un costo perché richiede tempo nell'immediato.

Ma la domanda giusta non è "quanto tempo mi costa scrivere i test?" ma "quanto tempo mi costa non averli?".

Senza test automatici, ogni modifica al codice richiede una sessione di verifica manuale che cresce con la complessità del sistema.

Ogni rilascio è preceduto da ore o giorni di test manuali ripetitivi.

Ogni bug in produzione genera un'analisi lunga perché non si sa da dove cominciare.

Il testing manuale non scala: scala solo quello automatico.

Con una suite di test ben costruita, il ciclo di sviluppo accelera.

Puoi fare refactoring senza paura perché i test ti dicono immediatamente se hai rotto qualcosa.

Puoi rilasciare con fiducia perché il sistema di CI ha già verificato tutto.

Puoi far crescere il team perché i nuovi arrivati possono modificare il codice e vedere i risultati senza dover conoscere l'intera applicazione.

Questa categoria non tratta il testing come un obbligo morale.

Lo tratta come uno strumento economico: quando si usa bene, riduce il costo del cambiamento e aumenta la velocità sostenibile del team.

Unit test, integration test, end-to-end: cosa testare e come scegliere

La piramide del testing non è una regola assoluta, ma un modello utile per allocare l'effort di testing in modo efficiente.

Unit test: verificano una singola unità di logica in isolamento, con tutte le dipendenze esterne sostituite da mock o stub. Sono veloci, deterministici e facili da mantenere. Coprono bene la logica di business, le trasformazioni dei dati e i casi limite. Non coprono bene le integrazioni reali.

Integration test: verificano che più componenti funzionino correttamente insieme, incluse le dipendenze reali come database, file system o servizi HTTP. Con Testcontainers for .NET si possono eseguire test su un database reale in Docker senza infrastruttura permanente. Sono più lenti degli unit test ma molto più realistici.

End-to-end test: verificano il sistema dall'esterno, simulando il comportamento dell'utente finale. Con Playwright per .NET si possono automatizzare test su browser reali. Sono i più costosi da scrivere e mantenere, e i più fragili. Si usano per i percorsi critici, non per coprire ogni scenario.

Il criterio pratico: unit test per la logica, integration test per le integrazioni, end-to-end per i flussi critici.

Non c'è una percentuale magica: dipende dal tipo di sistema.

TDD: quando funziona davvero e quando diventa controproducente

Test-Driven Development non è scrivere i test prima del codice per disciplina.

È usare i test per guidare il design: scrivere il test che descrive il comportamento desiderato, vedere il test fallire, scrivere il minimo codice per farlo passare, refactorizzare.

TDD funziona meglio quando il problema è ben definito e la logica è complessa: algoritmi, regole di business, trasformazioni di dati.

In questi contesti il test scritto prima costringe a pensare all'interfaccia prima dell'implementazione, spesso producendo un design più pulito e più facile da usare.

TDD funziona meno bene quando si esplora territorio sconosciuto, quando si integra con sistemi esterni con API non ancora stabili, o quando si costruisce UI.

In questi casi il test prima può essere un ostacolo: meglio esplorare, stabilizzare il design e poi aggiungere test.

L'errore più comune con TDD è interpretarlo come regola rigida invece che come strumento.

Chi abbandona TDD perché "non funziona sempre" perde il beneficio.

Chi lo applica meccanicamente anche dove non serve spreca energia.

Il professionista sa quando usarlo e quando no.

Mocking, dipendenze e la differenza tra test che proteggono e test che mentono

I mock sono necessari negli unit test per isolare la logica da testare.

Ma usati male producono test che passano anche quando il codice è sbagliato, o che falliscono quando si cambia un dettaglio implementativo invece di un comportamento.

Il principio fondamentale è: testa il comportamento, non l'implementazione.

Un test che verifica che un metodo venga chiamato esattamente una volta con esattamente questi parametri è fragile.

Un test che verifica che l'output del sistema sia quello atteso dato un certo input è robusto.

Con Moq e NSubstitute in .NET si possono creare mock precisi e verificabili.

Ma prima di usarli, vale la pena chiedersi: questo componente ha davvero bisogno di un mock, o posso usare una implementazione reale semplice?

Un repository in-memory è spesso meglio di un mock del repository: testa lo stesso comportamento con meno brittleness.

I test efficaci hanno tre caratteristiche: sono veloci (girano in millisecondi), sono deterministici (stesso risultato ogni volta), e quando falliscono ti dicono esattamente cosa è rotto e perché.