Marzo 22, 2015 - Commenti disabilitati su TDD .NET Clean Code That Works: TDD, testing, clean code e design in ambiente .Net

TDD .NET Clean Code That Works: TDD, testing, clean code e design in ambiente .Net

Corso di formazione sul TDD in ambiente .NET

“TDD .NET Clean Code That Works: TDD, testing, clean code e design in ambiente .Net” è il corso che i nostri trainers Pietro Di Bello e Boris Sclauzero hanno tenuto il 4, 5 e 6 Marzo.
Durante i tre giorni di corso, i partecipanti hanno potuto colmare il gap che spesso accomuna molti team che iniziano ad abbracciare i metodi agili, soprattutto Scrum, ovvero la mancanza di pratiche tecniche ed ingegneristiche adatte a sostenere lo sviluppo iterativo ed incrementale.

Senza l’adozione di opportune pratiche tecniche il processo di sviluppo è destinato ad un lento declino. Lo illustra molto bene Martin Fowler nel suo articolo “Flaccid Scrum”:

“If you're looking to introduce Scrum, make sure you pay good attention to technical practices. We tend to apply many of those from Extreme Programming and they fit just fine. XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.”

flaccid scrum

 

Gli argomenti principali del corso sono stati il Test-Driven Development (TDD) in ambiente .NET, il Refactoring, il Simple Design, il Design Incrementale e la Continuous Integration.
Il metodo formativo che adottiamo prevede di alternare in modo stretto sessioni teoriche ad esercitazioni pratiche.
Le esercitazioni pratiche sono state l’occasione per i partecipanti di prendere in mano la tastiera, lavorare in pair o in gruppi, assieme ai trainers, ed applicare i concetti appresi sul TDD .NET.
Le forme che preferiamo per le esercitazioni sono il “coding dojo” e i “code katas”, perché permettono di condividere la conoscenza e l’apprendimento, favoriscono lo scambio di opinioni e il focus sulle nuove modalità di approcciare il problema e il suo design.

TDD .NET Primo giorno

Il primo giorno si parte con un richiamo al manifesto agile: “Working software is the primary measure of progress”. Questo ci porta ad introdurre la test automation ed è l’occasione per rimarcare le differenze tra unit test, integration test e acceptance test, visto che in letteratura e nell’industria stessa purtroppo non esistono chiare ed univoche definizioni e spesso capita di vedere trattati test di integrazione come test unitari, o di non capire quale sia il ruolo dei test di accettazione.
Poi si parte con il TDD: una breve spiegazione del microciclo di sviluppo e subito una prima dimostrazione pratica, tenuta da noi, che illustra come risolvere in TDD un piccolo esercizio di programmazione. Questa dimostrazione consente di vedere “dal vivo” quale sia il ritmo del TDD, e come sia importante mantenere il ciclo breve e focalizzato (“red, green, refactor!”).

Dopo un’altra sezione teorica per approfondire i concetti del TDD e del refactoring , si passa al primo conding dojo dove le persone possono mettere le mani sulla tastiera e svolgere un semplice esercizio in TDD .NET.
Di solito affrontiamo questa sessione spendendo le prima ora in modalità “randori”, ovvero

  • un solo computer collegato ad un proiettore, in modo che tutti possano seguire
  • i partecipanti si alternano alla tastiera, in pair programming
  • ogni 10 minuti la coppia cambia: un nuovo partecipante raggiunge la postazione di sviluppo e sostituisce uno dei due pair della coppia

Dopo questa prima fase che consente a tutti di riflettere sull’impostazione iniziale dell’esercizio, dividiamo i partecipanti in gruppi, ognuno con la propria postazione di sviluppo, in modo che possano andare avanti da soli e riflettere con maggiore tranquillità sulle dinamiche del TDD su .NET e del refactoring.

TDD .NET Secondo giorno

Il secondo giorno ci si concentra sui principi di buon design, partendo proprio dal loro opposto: “come riconoscete che un design è cattivo?” chiediamo ai partecipanti.
Ecco quello che ci hanno detto:

TTD .NET Bad design

I sintomi del bad design secondo i partecipanti al corso

Questo è l’incipit per parlare di rigidità, fragilità ed immobilità, ovvero tre proprietà del bad design. E soprattuto per parlare di quali siano invece la caratteristiche del buon design.

E così introduciamo i SOLID principles ed altre importanti euristiche.
Le esercitazioni che seguono hanno lo scopo di riconoscere alcune palesi violazioni di questi principi, e di verificare sulla propria pelle come questo genere di violazioni coincida spesso con una difficoltà a scrivere test (testability) su una codebase esistente.
Per questo usiamo gli esercizi messi a punto da Luca Minudel che hanno il pregio di essere molto semplici e rapidi da fare, e di chiarire fin da subito la portata di principi come l’Open-Closed Principle (OCP) [pdf], il Dependency Inversion Principle (DIP) [pdf] e il Single Responsibility Principle (SRP) [pdf].
Dopo queste esercitazioni pratiche parliamo di altre euristiche utili e di comune utilizzo, come DRY [pdf] o Tell Don’t Ask [pdf], ma alla fine proponiamo una guida unica alla scrittura di un codice soddisfacente e buono: le quattro regole del simple design.

A design is simple as long as

  1. passes all tests
  2. expresses all the intents you want to express
  3. minimises duplication
  4. is small (has fewer classes/modules/packages…)

Nel corso delle successive esercitazioni mostriamo come tutti i principi discussi si possono sintetizzare in questi quattro punti.

Una delle domande che spesso ci fanno è:
“Come facciamo ad applicare il TDD a codice esistente?”

Per questo un’altra esercitazione che proponiamo è il Birthday Greetings Kata (versione C# e versione Java), che ci consente di parlare di testabilità e di come affrontare una codebase non testata e riuscire a scrivere dei test automatici, a fare TDD e a rifattorizzarla in sicurezza.

TDD .NET Terzo giorno

Il terzo giorno è tutto dedicato alla pratica: proponiamo al “team” di partecipanti un vero e proprio progetto, articolato con user stories e test di accettazione, con lo scopo di vedere concretamente come avviare i primi test in TDD .NET, come scrivere i test di accettazione, come mettere in piedi una piccola Continuous Integration sul cloud (CI).

TDD .NET Planning del gioco dell'oca

La lavagna del planning del gioco dell’oca

 

L’esercizio scelto è il Goose Game Kata, in una variante che permette poi di far evolvere il progetto in una applicazione web.
A fine esercizio c’è una vera propria demo, con tanto di partita finale con i partecipanti e code review del codice scritto dalle varie coppie.

TDD .NET Il gioco dell'oca

Soddisfazione finale: fare la demo e svolgere una partita al gioco dell’oca!

Alla fine della giornata facciamo una breve retrospettiva, per consentire a tutti di riflettere su quanto imparato, su cosa li ha sorpresi e su cosa faranno diversamente in futuro.

Dopo il corso, proponiamo sempre ai partecipanti un percorso di studio, per consentirgli di portare avanti i temi studiati. Il percorso di studio è composto di libri, articoli, video, presentazioni e soprattutto tantissimi esercizi di programmazione che consentono di allenare e affinare le proprie skill sul TDD, sul refactoring e sul simple design.

Alcune cose che abbiamo imparato noi durante questi corsi:

  • alternare sempre le esercitazioni pratiche alla teoria
  • insistere sull’importanza di non puntare a risolvere per forza gli esercizi che vengono dati, ma sul ragionare e riflettere sul modo diverso di lavorare che offre il TDD
  • nella composizione delle coppie o dei gruppi per le esercitazioni, preferire sempre l’eterogeneità di skill, per dare a tutti la possibilità di imparare

Alcuni riferimenti bibliografici su TDD .NET

Per maggiori informazioni sui Coding Dojo, su come organizzarli e strutturarli, raccomandiamo il libro di Emily Bache “The Coding Dojo Handbook”.

Alcuni libri consigliati per approfondire il TDD e in generale le buone pratiche di programmazione Object-Oriented:

Ed ecco qualche esercizio che consigliamo per affinare le proprie capacità di fare TDD:

Published by: xpeppers in Blog, Coding, XPeppers