a creazione di un software non è un processo semplice, vi sarà capitato di dover affrontare almeno uno di questi problemi: difficoltà comunicazione tra il team tecnico e il cliente, definizione superficiale dei requisiti e/o delle specifiche del software, scarsa attenzione ai test, fondamentali per verificare la qualità del prodotto. La pratica BDD (Behavior Driven Development) risolve queste difficoltà, creando un linguaggio comune comprensibile a tutti gli attori coinvolti, definendo contemporaneamente le specifiche dei requisiti e i test di accettazione/collaudo (sono gratis!!! ;-) ), e fornendo uno strumento intuitivo per monitorare l’avanzamento del progetto.

1. Sviluppare software a colpi di
test
Introduzione Al BDD
Enrico Marongiu - Maggio 2015
https://it.linkedin.com/in/enricomarongiu

2. Vi siete mai trovati in questa situazione?

3. “Potrebbe andare peggio.
Potrebbe piovere.

4. Perché BDD - Un po’ di storia
Test Driven Development
- Make it work
- Meno bachi
- Codice più snello
- Rilasci frequenti
Svantaggi
- Si perde di vista
l’obiettivo
- Facile applicarlo
male

5. Perché BDD - Un po’ di storia (II)
Behavior Driven
Development:
- Make it right
- evita feature bloat
- test funzionali e UAT
“for free”

6. Feature: Caricare un documento
Come utente contributore,
Voglio caricare un documento
Così che sia disponibile sulla digital library
Nota: Accetta pdf, ppt, odt, odf, sxw, txt
Scenario: caricamento pdf
Dato che sono connesso come “enrico”
Quando faccio click su upload
E seleziono il file “Huck_finn.pdf”
Allora posso inserire il titolo “Le avventure di
Huckleberry Finn” e l’autore “Mark Twain” e l’anno di
pubblicazione “1884”
Quindi compare un’anteprima della prima pagina in
formato png

7. specifica per esempi (no more lorem ipsum)
anticipa i problemi di design
aiuta a descrivere le possibili combinazioni
Vantaggi

8. Scenario: caricamento pdf con password fallisce
Dato che sono connesso come “enrico”
Quando faccio click su upload
E seleziono il file “documento_con_password.pdf”
Allora compare un messaggio di errore “il documento è
protetto da password”

9. Tutti capiscono, pochi sanno scrivere “bene”
Change request => duplicazione di
strumenti
Non sempre le storie e gli scenari sono
scritti in maniera comprensibile
Ostacoli

10. Feature: REST risorsa person
Accesso RESTful alla risorsa person
Scenario: GET person
Dato Oauth2 user: “enrico”
Quando GET /v1/person/enrico
Allora Response Content-Type:
“application/json”
E Http Status Code: “200”
E JsonPath “/result/name” = “enrico”

11. Feature: Caricare un documento
Come utente contributore,
Voglio caricare un documento
Così che sia disponibile sulla digital library
Nota: Accetta pdf, ppt, odt, odf, sxw, txt
I.N.V.E.S.T.
Le user story

12. Independent (Indipendente)
Caricamento di un pdf (6 story point)
Caricamento di un word (2 story point… se fatto dopo il pdf!)
Negotiable (Negoziabile)
La storia è un memo che dice “ricordati di parlarne col cliente”.
Valuable (utile e/o “monetizzabile”)
La connessione al database avviene attraverso un connection pool (???)
Le user story
Il sistema consente la connessione contemporanea di 50 utenti con 5 licenze
DB

13. Estimatable (il tempo di realizzazione deve essere quantificabile)
- non conosciamo la tecnologia? => spike
- non conosciamo il dominio? => parla col cliente
- la storia è troppo grande? => taglia
Small
- decomporre il problema
- ridurre il rischio di stime errate
Se la storia non è decomponibile (perché è molto complessa) => tagliatela
comunque!
Le user story (II)

14. Testable
Il software deve essere facile da usare
Il caricamento di un nuovo documento deve essere veloce
Il software deve essere sicuro
Le user story (III)
Il caricamento di un nuovo documento deve avvenire in meno di 2 secondi
il software deve essere immune alle top 10 OWASP vulnerabilities

15. Chi (persona / ruolo)
Quando
Cosa voglio fare
Come (senza dettagli tecnici)
Ma soprattutto… perché!
As… I want… so that...

16. Gestire le notifiche di un social network che consente di pubblicare
documenti e condividerli con altri.
Vogliamo ricevere notifiche quando:
- un utente ci segue
- un utente che seguiamo pubblica un contenuto
User story in pratica

17. “Cogito ergo +

18. (Follow)
Come utente della piattaforma
Voglio ricevere una notifica via email quando un altro
utente inizia a seguirmi
Così che io possa scegliere se seguirlo a mia volta =>
(più “utilità” da identificare)
(Attività)
Come follower di un utente
Voglio ricevere una notifica via email quando l’utente
seguito pubblica un nuovo contenuto
Così che io possa visualizzarlo e valutare se è di mio
interesse

19. (Attività digest)
Come follower di un utente
Voglio ricevere una notifica riepilogativa giornaliera
via email quando gli utenti che seguo pubblicano un nuovo
contenuto
Così che io possa visualizzarli e valutare se sono di
mio interesse

20. Scenario:
Dato che ho un utente “pippo”
E un utente “pluto”
Quando “pluto” segue “pippo”
Allora “pippo” riceve una notifica via email
contenente “pluto ha iniziato a seguirti”
Arrange, Act, Assert
ARRANGE
ACT
ASSERT

21. Gherkin è un linguaggio specifico di dominio leggibile in un contesto non
tecnico (business).
Il manager può LEGGERE, difficilmente SCRIVERE.
SCRIVERE è compito dello sviluppatore.
Struttura in sezioni
Suite - Funzionalità - Contesto - Scenario => Decomposizione del problema
Un linguaggio comune

22. Perché aggiungere “overhead”?
scrivere scenari
+ correggere scenari col cliente
+ scrivere il codice
scrivere codice
+ correggere codice dopo la demo col cliente
+ correggere regressions
+ correggere regression delle regression
scrivere codice
+ ( correggere codice dopo la demo col cliente
+ correggere regressions
+ correggere regression delle regression )
* (1+ 5 * probabilità che i bachi si manifestino
il venerdì sera o durante una demo)
Behat Come sempre

23. Gherkin è impostabile in diverse lingue, per cui è possibile evitare babeli
come:
Given che sono un utente registrato
When faccio click su “accedi”
Then sono connesso
#Nous avons il diabolo! Ugly come Salvatore, eh? My
little brother! Penitenziagite!!
Gherkin in altre lingue

24. Funzionalità: Notifica di following
Come utente della piattaforma
Voglio ricevere una notifica via email quando un altro utente inizia a
seguirmi
Così che io possa scegliere se seguirlo a mia volta
Contesto:
[Date|Dati|Data|Dato] che esiste “pluto_direct” con notifiche dirette
E che esiste “topolino_digest” con notifiche digest
E che esiste “pippo”
Scenario: Notifica di following
[Date|Dati|Data|Dato] che “pippo” non segue “pluto_direct”
E “pippo” è un utente attivo
Quando “pippo” segue “pluto_direct”
Allora “pluto_direct” riceve una mail di notifica diretta
Ma “pluto_direct” non riceve una mail di notifica digest

25. Funzionalità: Notifica di following
[…]
Schema dello scenario: Notifica di following
Dato che esiste <nuovofollower>
E esiste <followed> con notifiche dirette
Quando <nuovofollower> segue <followed>
Allora <followed> riceve una mail di notifica diretta contenente
<nuovofollower> e “ ti sta seguendo”
Ma <followed> non deve ricevere una mail di notifica digest
Esempi:
| nuovofollower | followed |
| pluto | pippo_digest |
| topolino_digest | pippo_digest |
| pluto | pippo_digest |
| paperoga | pippo_digest |

26. Contesto:
Dato che esistono gli utenti:
| username | password |
| paperino | password |
| paperina | password |
| qui | password |
| quo | password |
| qua | password |
Contesto <=> Esempi

27. “Se una cosa può andar male,
lo farà.

28. Scenario: Doppie notifiche
Dato che “pippo” segue già “pluto_direct”
Quando “pippo” segue “pluto_direct”
Allora “pluto_direct” non riceve una mail di notifica diretta
E “pluto_direct” non riceve una mail di notifica digest
Scenario: Preferenza non impostata
Dato che esiste “pluto_direct” con preferenze di notifica non
impostate
Quando “pippo” segue “pluto_direct”
Allora “pluto_direct” riceve una mail di notifica …?

29. Let’s swing!

35. Il cliente ti dà piena autonomia… fino alla scadenza. [immagine altalena]
Il cliente ti dà un mese. Alla settimana 1 vede che hai già fatto 10 scenari
in una settimana su 20 totali. La settimana dopo vuole il prodotto finito.
Inizi a usare BDD per la prima volta su un progetto avviato.
Inizi a usare BDD per la prima volta su un progetto nuovo. Poi ti “scordi”
di applicarlo qua e là. Il codice si rompe. Non hai riferimenti per le
regression. Lo sforzo di applicazione “a ritroso” è tale che… abbandoni
per sempre BDD.
Quando non usare BDD

36. “
Ottimo lavoro ragazzi ma...

37. Prossimo appuntamento:
- scriviamo API RESTful
- utilizziamo un ambiente pronto all’uso
- alcuni utili metodi di assertion
...non è ancora il momento di farsi
i complimenti a vicenda

38. “Grazie!

39. http://2015.phpday.it/talk/behatminkphantomjs-test-all-the-things/
http://www.slideshare.net/chassa/2013-0603specification-byexamplewithgherkinchristianhassa
http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons
http://martinfowler.com/bliki/BusinessReadableDSL.html
http://www.slideshare.net/railsconf/below-and-beneath-tdd-test-last-development-and-other-real-
world-test-patterns-presentation
https://robots.thoughtbot.com/writing-better-cucumber-scenarios-or-why-were
Libri:
Gojko Adzic - Specification by example http://specificationbyexample.com/
Mike Cohn - User stories applied http://www.mountaingoatsoftware.com/books/user-stories-
applied
Riferimenti