Behavior Driven Development in Domain Driven Design

1. BDD { Bring(UserStories) .SharedWith(DomainExpert) .Into(YourCompiledCode); } Omid Ehsani

2. Grazie!

3. Dal Dominio al Codice (1) Domain Abstraction Model Realization Design

4. Dal Dominio al Codice (2) Quale è il vostro approccio? Quando scrivete la «prima» riga di Codice? Quante trasformazioni mentali occorrono dalla modellazione del Dominio alla realizzazione del Codice? E’ possibile comprendere il requisito realizzato a partire dal Codice (o viceversa)? Come fate a dimostrare al Domain Expert il completamento di un requisito?

5. Gli aspetti di Design (1) Aspetti Strutturali Bounded Contexts Aggregates (e altri building blocks) Static Diagrams Design Patterns

6. Gli aspetti di Design (2) Aspetti Comportamentali User Stories / Use Cases Test Cases Dynamic Diagrams Automated Testing (TDD)

7. DEMO TDD nel Codice

8. Evoluzione del TDD Il percorso di maturazione di sviluppo TDD: Si inizia a scrievre unit-test Si acquisisce maggiore confidenza nel codice Scrivendo prima il test si evita il gold-plating Il test si rivela utile alla documentazione del codice Il test diventa strumento di design emergente Il focus di TDD si sposta dal test al comportamento Il comportamento descrive l’interazione delle componenti, il mocking diventa imprescindibile Non tutti gli sviluppatori catturano l’enorme valore di TDD dal punto 5 in poi

9. BDD: Un altro approccio Behaviour Driven Development, nasce dal pensiero di Dan North, con l’obiettivo di: Focalizzare lo sviluppo sul valore per il Business, prioritizzato e verificabile Sfruttare un vocabolario comune (Ubiquitous Language) tra la Tecnologia e Business Avere una visione comnue del sistema tra la Tecnologia e il Business, attraverso i Behaviour Non è una nuova metodologia o tecnologia, ma una revisione di buone pratiche esistenti.

10. BDD: dimmi...la storia! Si parte dai requisiti (non necessariamente User Story, ma si prestano molto bene): Average Daily Price Calculation In order to comply with company target pricing As a sales account I want to be told the average daily price of my WorkOrder WorkOrder +AverageDailyPrice Job +Duration +Amount

11. BDD: Gli scenari... (1) Ogni requisito, se ben fatto, dovrebbe essere accompagnato da scenari che permettano di: Descrivere il comportamento normale del sistema, esemplificando il requisito con dati di input e output attesi. Individuare i casi limite e descrivere i comportamenti specifici del sistema in questi casi. Definire i criteri, oggettivamente verificabili, di accettazione dell’implementazione del requisito.

13. Another with duration 1 days and amount 700

14. Another with duration 2 days and amount 1200The average daily price should be 550 WorkOrder +AverageDailyPrice Job +Duration +Amount

15. Gherkin Language Il linguaggio «Gherkin» permette di esprimere gli scenari BDD attraverso un DSL compilabile: Scenario: Calculate Average Daily Price on 3 jobs Given I have created a new WorkOrderAnd I have added a Job with Duration 5 days and Amount 2500 And I have added a Job with Duration 2 days and Amount 1200 And I have added a Job with Duration 1 days and Amount 700 When I ask the average daily price Then the Average Daily Price should be 550 Il Linguaggio Gherkin è stato definito nel progetto Cucumber (http://cukes.info/)

16. DEMO Un esempio di BDD

17. BDD: Ma come fa...? I tool ci aiutano Ce ne sono tanti e per diversi linguaggi (alcuni più maturi, altri in progress, altri confluiti nei primi o abbandonati!) Le frasi Gherkin diventano eseguibili Generazione automatica del codice Interpretazione da parte del tool Le frasi invocano parti (step) del nostro codice Per convenzione o per altri meccanismi di binding Gli step interagiscono con il Codice di produzione Domain Model Controller MVC Qualsiasi cosa vogliamo testare!

18. Demo Domain Model WorkOrder SalesAccount Client SalesLine +AverageDailyPrice +Status +FullName +Email +ComapnyName +Name PaymentTranche Job +ExpectedInvoiceDate +Duration +Amount +CompletionState

19. DEMO BDD con SpecFlow

20. BDD vs TDD BDD non è un’alternativa a TDD BDD è costruito “sopra” TDD, l’approccio è lo stesso Si inizia con BDD, e sifinisce con TDD! Prima il focus sui requisiti (BDD) Poi sul design e implementazione di dettaglio(TDD) Un ciclo di red-green-refactor di BDD comprende diversi cicli di red-green-refactor di TDD

21. Benefici di BDD (1) Il punto di partenza è un requisito Focus sul valore per il Business, no gold-plating Meno trasformazioni mentali per tradurre il requisito in codice Obiettivo da raggiungere: green sulla feature L’Ubiquitous Language fluisce naturalmente dal requisito al codice

22. Benefici di BDD (2) Il requisito fa parte del Codice Il Codice è l’unico artefatto vivente che rappresenta lo stato dell’arte del sistema La documentazione dei requisiti implementati è aggiornata con il Codice Le feature diventano punto di partenza per l’introduzione di nuovi svilluppatori nel progetto Requisiti testati automaticamente Regressione sotto controllo a livello dei requisiti Test di accettazione in gran parte automatizzata Evidenza di implementazione dei requisiti anche per stakeholder meno tecnici

23. Insignt: Gli effetti di BDD In uno stesso dominio le frasi Gherkin si ripetono I comportamenti sono ricorrenti Si crea uno strato di Codice per manipolare il Domain Model attraverso frasi Gherkin Nasce una nuova grammatica componibile Diventa usa sorta di DSL Un layer di scripting sul Domain Model La produttività per la scrittura di nuove feature e scenari aumenta esponenzialmente

24. BDD Q & A Grazie!