Acceptance Test Driven Development

Giorgio Marchetti

2

“Mi serve per domani, ma è facile…”

Ho un elenco di scontrini.

Obiettivo

Nel caso degli scontrini con cross selling (ossia con prodotti appartenenti a

categorie diverse, ma acquistati nella stessa transazione), voglio sapere quali

scontrini contengono la categoria B e la categoria W e che altre categorie

contengono

3

“Fatto!”

• Welcome Change: siamo un team agile, il cambiamento è il nostro pane

quotidiano

• Delight your customer: soddisfare il cliente è la nostra priorità

• Feel good!: detto, fatto… Flash Gordon? Sei fuori!

4

“Però non mi torna”

Ad esempio: lo scontrino 43136 contiene sia B (tre referenze) che C (una

referenza)

ma non compare tra i risultati

Perché?

5

Agenda di oggi

IntroduzioneCos’è ATDD

La matrice dei testDov’è ATDD

La TriadeChi fa ATDD

Test-first! Test-when??!!Quando si fa ATDD

A chi serve veramente?Perché si fa ATDD

Restiamo in contattoCondividiamo i nostri esperimenti

IntroduzioneCos’è ATDD

Quando l’incertezza è

bassa e la conoscenza del dominio alta, l’enfasi è sulla conformità.

Quando gli obiettivi sono chiari, ma non

esiste una soluzione nota, l’enfasi è sulla

fattibilità.

Quando gli obiettivi sono

mutevoli o incerti, l’enfasi è

sull’apprendimento

Requisiti testati e testabili10

Gli AT non sono test di accettazione tradizionali

Non sono eseguiti dall’utente finale dopo l’implementazione, al fine di verificare se il sistema funziona secondo le specifiche contrattualizzate

Gli AT non sono System Tests

Non sono test scritti dai tester leggendo il documento dei requisiti

Gli AT non sono Acceptance Criteria

Non sono informali

Gli AT sono indipendenti dall’implementazione

Validano innanzitutto i requisiti, e poi possono essere usati per testare l’implementazione

Gli AT sono definiti collaborativamente

Nascono dalla stretta collaborazione tra cliente/utente, sviluppatore e tester e sono il pilastro su cui fondare una comune comprensione del dominio dell’applicazione

Ok, I want to do the thing right, but how I know it is the right thing?

L’albero della conoscenza11

… dei requisiti

DDD

Specification by Example

BDD

Executable Specifications

Evans

Adzic North

Beck / XP

12

Tanti nomi, una sola cosa?

ATDD – Acceptance Test Driven Development:

Il focus è sul concetto di “accettazione” e su quello di verifica. E’ naturale il nesso con i cosiddetti Acceptance Criteria, che sono parte essenziale della DoR (Definition of Ready) e della DoD (Definition of Done)

BDD – Behaviour Driven Development (North):

L’attenzione è sul comportamento del sistema. È forse l’acronimo più popolare.

Specification by Example (Adzic):

La definizione di Adzic si libera del “DD” e mette al centro il processo di costruzione delle specifiche tramite esempi

Executable Specifications:

Qui l’accento è sulla “specifica” come vero e proprio test eseguibile e automatico

DDD – Domain Driven Design:

Ubiquitous language! Conoscere il dominio per avere il dominio

Una questione di punti di vista

La matrice dei testDov’è ATDD

“

”

ATs do not indicate how to

design a solution.

Rather, they are a

communication mechanism.

Ken Pugh

“

”

Altough the test are absolute (…) they also

form a point of discussion

between the customer and the engineers.

Ken Pugh

La TriadeChi fa ATDD

17

Ecco la nostra triadeSenza dimenticare il “quarto uomo”

Mario Volubile

Luca Codice Mara Scrupoli Aldo PortafogliStakeholder Developer Tester Chief Financial

Officer

“

”

Conversations around examples,

expressed in a form that can be

easily

automated, to reduce lost

information and misunderstanding

s

John Ferguson Smart

Alla ricerca di un linguaggio comune19

Dal dominio del linguaggio al linguaggio di dominio

Gherkin20

Gherkin Script: GWT

Gli script Gherkin sono una forma strutturata di linguaggio quotidiano Given – indica qualcosa che è dato per vero nello scenario When – indica un evento nello scenario Then – indica il risultato atteso

“And” e “But”

Per migliorare la leggibilità sono supportate anche le parole chiave “And” e “But”

Comprensibilità

Le clausole sono espresse nel linguaggio e con la sintassi naturali e quindi sono comprensibili anche da chi si occupa di business e non di coding.

DSL

Le clausole Gherkin finiscono per costituire un “Domain Specific Language” del tutto indipendente dal linguaggio di programmazione usato per l’implementazione

Dato che è scritto in Gherkin, quando leggo lo scenario, allora lo capisco

Tabelle21

Anche il colpo d’occhio vuole la sua parte

Test-first! Test-when??!!Quando si fa ATDD

Subito!23

Identificare i desirements

Associarli ad un obiettivo di business

Sfidarli “by example”

“Se sopravvivono allora vanno bene” (Charles Darwin… credo)

Un computer farà quello che gli dici, non quello che vuoi… meglio dirla giusta

Approccio outside-in24

Iniziare dalla fine per iniziare bene

Cosa si può ottenere25

Fare attenzione agli effetti indesiderati

Ciclo di sviluppo26

Sembrava facile….ma poi

Automazione e tools27

Run, test run

A chi serve veramente?Perché si fa ATDD

29

Allo stakeholder

Dai Desirements ai Requirements, e poi giù fino alle Specifications: non è più un viaggio solitario

Costruire esempi aiuta a chiarire le idee

I casi-limite come strumento di stress dei miei desideri

Come sapere se l’obiettivo è raggiungibile: si può fare, e se sì, costerà tantissimo?

Come sapere se ho ottenuto proprio ciò che mi serve?

Idee chiare, amicizia lunga

Al team di sviluppo30

Finalmente sono sicuro che sto implementando la cosa giusta

Il valore di ciò che consegno è stato esplicitato

Posso sapere quando ho finito

Posso sapere se ho rotto qualcosa

Ehi… ma questi sono i regression test… wow!

“Ragazzi, chi si becca il task della documentazione? Ah… non c’è nessun task della documentazione…”

Beh sì… ci piace vincere facile

A tutti i protagonisti31

“Panico: dobbiamo rivedere quella funzione sviluppata tre mesi fa. Qualcuno si ricorda qualcosa?”

“Sto leggendo gli acceptance test. Rifammi la domanda tra qualche minuto.”

“Panico: non trovo più i miei appunti. Come si è deciso di integrare quel processo nella procedura degli

acquisti?”

“Sto leggendo gli acceptance test. Rifammi la domanda tra qualche minuto.”

“Panico: ci siamo accorti che questo nuovo processo non va bene. Qualcuno si ricorda com’era prima?”

“Sto leggendo la versione precedente degli acceptance test. Rifammi la domanda tra qualche minuto.”

“Panico: abbiamo una quality issue su questo articolo di due anni fa. Quali erano le norme di compliance

implementate a sistema all’epoca?”

“Sto leggendo quella versione degli acceptance test. Rifammi la domanda tra qualche minuto.”

Perché la memoria è corta

A chi verrà32

“Ciao! Sono il nuovo sviluppatore. Da quale di queste seicento classi comincio per capirci qualcosa?”

“Lascia stare il codice per ora… qui trovi gli acceptance test. Se fossi in te partirei dalla funzione X”

“E’ cambiato il nostro referente presso il cliente… chi gli spiega come funziona il sistema?”

“Gli mando il link alla wiki, e poi se serve qualche approfondimento ci parlo direttamente”

Ai posteri la facile sentenza

Restiamo in contattoCondividiamo i nostri esperimenti

34

Restiamo in contattoCondividiamo i nostri esperimenti

IndirizzoV.le Venezia 11133100 Udine (UD)

Telefono0432 23 48 38

Email / Websitegmarchetti@emme4.comwww.emme4.com

35

La mia prima scelta La mia prima sceltaWTF

...forse l’avevo già fatta

La mia prima sceltaok...

c’è un dannato bug nella

funzione di ranking

Letture“Non ti preoccupare mai della teoria fintantoché il sistema fa ciò che si è supposto faccia” – Robert A. Heinlein

36

By Example al

quadrato

Alla radice del

problemaSe non siete convintiTestimonianze convincenti

dalla trincea!

Letture“In teoria, la pratica e la teoria rappresentano la stessa cosa. In pratica ciò non è vero” – Yogi Berra