1 of 25

Workshop:�Test Driven Development

Lorenzo Spinelli

Tiziano Pessa

2 of 25

What are we going to do?

Brief intro: TDD - What, How & Why?

Hands on session - let’s code together

3 of 25

TDD_

What

How

Why?

4 of 25

image credit: Adobe stock

Production failures

5 of 25

Study of 198 production failures

(Paper)

https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf

6 of 25

58%

Easily avoided with adequate test coverage

7 of 25

We need a powerful error detection protocol

8 of 25

it’s about ensuring that when we push code into production

we do so with the confidence that it won’t break anything.

It's not about admitting that we’re not good developers;

9 of 25

Testing

10 of 25

Testing (verb)

Evaluating a system, product, or software to assess its functionality, performance, reliability, and quality

by executing it under specific conditions to identify defects and ensure it meets requirements

11 of 25

The "No time for testing" death spiral

Stress

Less test

Automated tests

Testare il software ci dà garanzie sul suo corretto funzionamento, anche a fronte di modifiche future. Il problema è che non sempre siamo nelle condizioni ideali per testare il nostro software al meglio. Tipicamente quello che succede in situazioni di stress è che, dato che siamo sotto pressione, non abbiamo tempo per testare il software, ma sfortunatamente questo innesca un circolo vizioso in cui la mancanza di confidenza nel nostro software fa ulteriormente aumentare il nostro stress (e il numero di bug), ecc.

Come possiamo rompere questo circolo vizioso? Dobbiamo cambiare qualcosa e il cambiamento è l'introduzione dei test automatici. Una volta che avete una suite di test automatici che copre il vostro software non avete bisogno di tempo per testare, basta premere un pulsante e potrete essere sicuri di non aver rotto le funzionalità di base del vostro software.

12 of 25

The Test Pyramid

https://martinfowler.com/articles/practical-test-pyramid.html

BDD

TDD

Esistono moltissimi tipi di test automatici.

La Piramide dei test è un concetto introdotto da Micheal Cohn nel suo libro Succeeding with Agile. Questa è la piramide originale suggerita da Cohn, che tipicamente prevedeva test unitari, test di integrazione (service test) e test sull'interfaccia (e2e test). In realtà col tempo le tipologie di test si sono ulteriormente specializzate e oggi nella piramide si fanno rientrare decine di tipi diversi di test. Ma il concetto non cambia: la nostra piattaforma dovrebbe avere molti test unitari, che sono isolati e veloci da eseguire, mentre via via che i test diventano di più alto livello diventano anche più complessi, integrati e lenti, ma soprattutto più costosi da fare e manutenere e di conseguenza ce ne sono tendenzialmente meno.

Ci sono diversi approcci al testing, quando si approccia lo sviluppo partendo dai test si parla di TDD o Test Driven Development per i test che si trovano nella parte bassa della piramide, e BDD o Behaviour Driven Development per i test che si trovano nella parte alta della piramide.

13 of 25

What is TDD?

Writing tests before writing the code

Writing code only to pass the tests

TDD is about expressing intent

14 of 25

The TDD process

1. Write a Test

2. Run the Test

Repeat

Red phase

Green phase

Gray phase

3. Write the Code

4. Run the Test Again

5. Refactor

Nel processo TDD sono previste queste fasi:

Scrivere un test: Si inizia scrivendo un test per una nuova caratteristica o funzionalità. Questo test definisce cosa deve fare il codice.
Eseguire il test: Eseguire il test per vederlo fallire. Questa fase conferma che il test è valido e che la funzionalità non è ancora stata implementata.
Scrivere il codice: Successivamente, scrivete la quantità minima di codice necessaria per far passare il test.
Eseguire di nuovo il test: Eseguite nuovamente il test. Se passa, si sa che il codice soddisfa il requisito definito nel test.
refactor: Se il test è stato superato, è necessario migliorare il codice, assicurandosi che sia pulito ed efficiente senza modificarne la funzionalità.
Ripetere: tornare al punto uno per la prossima caratteristica o funzionalità.

15 of 25

Two simple rules

Write new code only if an automated test has failed
Eliminate duplication

Il processo è così semplice! Ma dobbiamo seguire alcune regole. La prima è:�il ciclo Red-Green-Refactor:

Red:

Iniziamo scrivendo un test per la nuova feature o funzionalità che vogliamo aggiungere.
Eseguiamo il test, che dovrebbe fallire perché la funzione non è ancora stata implementata.
Questa fase “rossa” conferma che il test funziona e che il codice deve essere scritto.

Green:

Ora, scriviamo la minima quantità di codice necessaria per far passare il test.
Eseguiamo di nuovo il test, che dovrebbe essere superato, trasformando il risultato del test da “rosso” a “verde”.

Refactor:

Una volta superato il test, torniamo indietro e ripuliamo il codice.
Semplifichiamo e ottimizziamo senza cambiare le funzioni.
Il test dovrebbe passare anche dopo il refactoring, assicurando che il codice sia più pulito ed efficiente.

Questo processo si ripete per ogni nuova funzionalità aggiunta.�Ci sono altre regole, ma le tratteremo più avanti. Per ora, concentriamoci su come il TDD migliora la progettazione e ci aiuta a creare un codice migliore, non solo test.�E perché è molto meglio dei test unitari.

16 of 25

TDD phases

Write a little test that doesn't work

Red phase

Green phase

Gray phase

Make the test work quickly

Eliminate duplication

Il processo è così semplice! Ma dobbiamo seguire alcune regole. La prima è:�il ciclo Red-Green-Refactor:

Red:

Iniziamo scrivendo un test per la nuova feature o funzionalità che vogliamo aggiungere.
Eseguiamo il test, che dovrebbe fallire perché la funzione non è ancora stata implementata.
Questa fase “rossa” conferma che il test funziona e che il codice deve essere scritto.

Green:

Ora, scriviamo la minima quantità di codice necessaria per far passare il test.
Eseguiamo di nuovo il test, che dovrebbe essere superato, trasformando il risultato del test da “rosso” a “verde”.

Refactor:

Una volta superato il test, torniamo indietro e ripuliamo il codice.
Semplifichiamo e ottimizziamo senza cambiare le funzioni.
Il test dovrebbe passare anche dopo il refactoring, assicurando che il codice sia più pulito ed efficiente.

Questo processo si ripete per ogni nuova funzionalità aggiunta.�Ci sono altre regole, ma le tratteremo più avanti. Per ora, concentriamoci su come il TDD migliora la progettazione e ci aiuta a creare un codice migliore, non solo test.�E perché è molto meglio dei test unitari.

Eliminare la duplicazione significa eliminare le dipendenze: nel software la duplicazione è spesso un sintomo di dipendenze e quindi di moduli accoppiati, segno di una cattiva architettura. Nella fase di refactoring bisogna quindi concentrarsi sull'eliminare la duplicazione per rendere i moduli più indipendenti e debolmente accoppiati. Questo si applica non solo al codice ma anche (e sopratuttto nel TDD) alla duplicazione tra i test e il codice.

17 of 25

Key benefits of TDD

High test coverage
Meaningful tests
Early problem detection
Less debugging
Improved design
Easier to maintain

18 of 25

The attributes of good code

Modular
Loosely coupled
High cohesion
Separation of concerns
Information hiding

19 of 25

The attributes of good code

The attributes of testable code

Modular
Loosely coupled
High cohesion
Separation of concerns
Information hiding

20 of 25

TDD: the talent amplifier

Testing is not a magic fix!

It won't instantly make you the best programmer in the world.

Bad programmer

Less bad programmer

Good programmer

Better programmer

Great programmer

Greater programmer

21 of 25

Any questions so far?

22 of 25

TDD_

Let’s code!

23 of 25

Goal

Supplier	Quantity	Price	Total
CodeCorp	1000	25 USD	25000 USD
BugBusters	400	150 CHF	60000 CHF

Total			65000 USD

From	To	Rate
CHF	USD	1.5

Durante il workshop, svillupparemo un sistema per produrre un report multi-valuta per la fatturazione, come questo:

Spiegazione del report:

Intestazione: Il report conterrà il nome dell'azienda, il periodo di riferimento e il titolo "Report Multi-Valuta".
Tabella delle fatture:

Colonne:

Data della fattura
Numero della fattura
Nome del cliente
Importo in valuta originale
Valuta originale
Tasso di cambio applicato
Importo in valuta di destinazione

Totali: Alla fine del report, ci saranno le somme totali per ciascuna valuta.

Specifiche sui tassi di cambio:

Dobbiamo definire i tassi di cambio tra le diverse valute coinvolte.
Possiamo utilizzare un approccio semplice, come un dizionario che mappa le valute alle loro rispettive quotazioni rispetto a una valuta di base (ad esempio, euro).
È importante considerare che i tassi di cambio possono variare nel tempo, quindi potremmo anche voler implementare una funzionalità per aggiornare i tassi di cambio in modo dinamico.

Pronti a iniziare a scrivere il codice per questo sistema?

24 of 25

https://github.com/firenzedev/tdd-workshop

25 of 25

We want to drive the development with automated tests

Quickly add a test.
Run all tests and see the new one fail.
Make a little change.
Run all tests and see them all succeed.
Refactor to remove duplication.