Sviluppare software a colpi di test

Introduzione Al BDD

Enrico Marongiu - Maggio 2015https://it.linkedin.com/in/enricomarongiu

Vi siete mai trovati in questa situazione?

“Potrebbe andare peggio.

Potrebbe piovere.

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

Perché BDD - Un po’ di storia (II)

Behavior Driven Development:- Make it right - evita feature bloat- test funzionali e

UAT “for free”

Feature: Caricare un documentoCome utente contributore,

Voglio caricare un documento Così che sia disponibile sulla digital library

Nota: Accetta pdf, ppt, odt, odf, sxw, txt

Scenario: caricamento pdfDato che sono connesso come “enrico”Quando faccio click su uploadE 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

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

Vantaggi

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”

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

Ostacoli

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”

Feature: Caricare un documentoCome 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

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

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)

TestableIl software deve essere facile da usareIl caricamento di un nuovo documento deve essere veloceIl 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

Chi (persona / ruolo)QuandoCosa voglio fareCome (senza dettagli tecnici)Ma soprattutto… perché!

As… I want… so that...

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

“Cogito ergo +

(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

(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

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

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 sezioniSuite - Funzionalità - Contesto - Scenario => Decomposizione del problema

Un linguaggio comune

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

Gherkin è impostabile in diverse lingue, per cui è possibile evitare babeli come:

Given che sono un utente registratoWhen faccio click su “accedi”Then sono connesso

#Nous avons il diabolo! Ugly come Salvatore, eh? My little brother! Penitenziagite!!

Gherkin in altre lingue

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

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 |

Contesto: Dato che esistono gli utenti: | username | password | | paperino | password | | paperina | password | | qui | password | | quo | password | | qua | password |

Contesto <=> Esempi

“Se una cosa può andar male,

lo farà.

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 …?

Let’s swing!

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

“Ottimo lavoro ragazzi ma...

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

“Grazie!

http://2015.phpday.it/talk/behatminkphantomjs-test-all-the-things/http://www.slideshare.net/chassa/2013-0603specification-byexamplewithgherkinchristianhassahttp://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-conshttp://martinfowler.com/bliki/BusinessReadableDSL.html http://www.slideshare.net/railsconf/below-and-beneath-tdd-test-last-development-and-other-real-world-test-patterns-presentationhttps://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