Chi Sono

Il viaggio che mi ha portato qui

L'inizio: test manuali e frustrazioni

Il mio primo lavoro in una multinazionale mi ha messo di fronte a un progetto gigantesco, composto da decine di microservizi. L'unico modo per testare qualcosa era rilasciare sul server di sviluppo. Ogni volta che dovevamo testare un bug in produzione, partiva una routine estenuante: trovare i dati giusti, replicare il problema, controllare i log.

La scoperta degli unit test

Un giorno mi viene chiesto di scrivere test per raggiungere l'80% di code coverage. Non sapevo nemmeno dell'esistenza di questi strumenti. Scoprire che potevo testare tutto in locale usando file JSON mi sembrò magia nera. Quella scoperta mi affascinò: testare senza passare dal server sembrava surreale.

Il primo approccio al TDD (e le prime difficoltà)

Affascinato, cominciai a documentarmi su MSTest e mi imbattei nel TDD. "Per applicare il TDD, bisogna scrivere i test prima del codice." Rimasi perplesso: come posso scrivere i test senza avere il codice? Decisi di immergermi nello studio del TDD, ma i risultati non arrivavano: i test funzionavano, ma dalla UI trovavo sempre casi non coperti. Ogni modifica rompeva qualcosa. Era frustrante, quasi più lungo del test manuale.

Non arrendersi

Nonostante le difficoltà, non volevo rinunciare. Sapevo che non potevano esistere metodologie solo teoriche: il modo ci doveva essere, mi stava sfuggendo qualcosa. Continuai a studiare, a fare esperimenti, ma sentivo che mi mancava un pezzo fondamentale.

Il cambiamento: ATDD e Outside-In Development

Quando ero sul punto di mollare, un collega mi consigliò il Software Crafting Programme di Alessandro di Gioia e Marco Consolaro. Nel corso scoprii l'ATDD (Acceptance Test-Driven Development) e l'Outside-In Development. Fu la svolta: imparai a vedere tutto dall'ottica dell'utilizzatore finale, concentrandomi sul valore che avrebbe ottenuto.

Capì che gli Unit Test, se non usati correttamente, ti fanno solo perdere tempo. La parte fondamentale è vedere il software per quello che è: uno strumento a servizio degli esperti di business.

La missione: aiutare altri team

Da quel momento, ho compreso che i test sono uno strumento a supporto dello sviluppatore, ma la chiave è la collaborazione tra dev e business. L'ATDD diventa documentazione viva che certifica cosa il software è in grado di fare.

Ora aiuto altri team a evitare le mie frustrazioni iniziali e a costruire software che dura nel tempo, usando metodo e architettura solida.

Il mio stack tecnologico

Speaker & Divulgazione Tecnica

Credo fortemente nella condivisione della conoscenza. Intervengo regolarmente a conferenze nazionali e meetup per parlare di architettura software, testing, e best practices nello sviluppo .NET.

Ho parlato a

Altre competenze & interessi

• 🧠

  PNL e Crescita Personale

  Formazione in Programmazione Neuro-Linguistica e tecniche di coaching, che applico nel lavoro con i team per migliorare comunicazione e collaborazione.

• ⚡

  Metodologie Agili & XP

  Appassionato di metodologie agili e Extreme Programming. Credo fortemente in pratiche come pair/mob programming, TDD e continuous integration.

• 📚

  Apprendimento Continuo

  Sempre curioso di imparare nuove tecniche, pattern architetturali e approcci innovativi allo sviluppo software. Condivido regolarmente quello che imparo.