Upload
enrico-marongiu
View
38
Download
1
Embed Size (px)
Citation preview
Sviluppare software a colpi di test
Introduzione Al BDD
Enrico Marongiu - Maggio 2015https://it.linkedin.com/in/enricomarongiu
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
(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
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 …?
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
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
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