BDD in DDD

858 views

Published on

Behavior Driven Development in Domain Driven Design

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
858
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

BDD in DDD

  1. 1. BDD<br />{ <br /> Bring(UserStories)<br /> .SharedWith(DomainExpert)<br /> .Into(YourCompiledCode); <br />}<br />Omid Ehsani<br />
  2. 2. Grazie!<br />
  3. 3. Dal Dominio al Codice (1)<br />Domain<br />Abstraction<br />Model<br />Realization<br />Design<br />
  4. 4. Dal Dominio al Codice (2)<br />Quale è il vostro approccio?<br />Quando scrivete la «prima» riga di Codice?<br />Quante trasformazioni mentali occorrono dalla modellazione del Dominio alla realizzazione del Codice?<br />E’ possibile comprendere il requisito realizzato a partire dal Codice (o viceversa)?<br />Come fate a dimostrare al Domain Expert il completamento di un requisito?<br />
  5. 5. Gli aspetti di Design (1)<br />Aspetti Strutturali<br />Bounded Contexts<br />Aggregates (e altri building blocks)<br />Static Diagrams<br />Design Patterns<br />
  6. 6. Gli aspetti di Design (2)<br />Aspetti Comportamentali<br />User Stories / Use Cases<br />Test Cases<br />Dynamic Diagrams<br />Automated Testing (TDD)<br />
  7. 7. DEMO<br />TDD nel Codice<br />
  8. 8. Evoluzione del TDD<br />Il percorso di maturazione di sviluppo TDD: <br />Si inizia a scrievre unit-test<br />Si acquisisce maggiore confidenza nel codice<br />Scrivendo prima il test si evita il gold-plating<br />Il test si rivela utile alla documentazione del codice<br />Il test diventa strumento di design emergente<br />Il focus di TDD si sposta dal test al comportamento<br />Il comportamento descrive l’interazione delle componenti, il mocking diventa imprescindibile<br />Non tutti gli sviluppatori catturano l’enorme valore di TDD dal punto 5 in poi<br />
  9. 9. BDD: Un altro approccio<br />Behaviour Driven Development, nasce dal pensiero di Dan North, con l’obiettivo di:<br />Focalizzare lo sviluppo sul valore per il Business, prioritizzato e verificabile<br />Sfruttare un vocabolario comune (Ubiquitous Language) tra la Tecnologia e Business<br />Avere una visione comnue del sistema tra la Tecnologia e il Business, attraverso i Behaviour<br />Non è una nuova metodologia o tecnologia, ma una revisione di buone pratiche esistenti.<br />
  10. 10. BDD: dimmi...la storia!<br />Si parte dai requisiti (non necessariamente User Story, ma si prestano molto bene):<br />Average Daily Price Calculation In order to comply with company target pricing <br />As a sales account I want to be told the average daily price of my WorkOrder<br />WorkOrder<br />+AverageDailyPrice<br />Job<br />+Duration<br />+Amount<br />
  11. 11. BDD: Gli scenari... (1)<br />Ogni requisito, se ben fatto, dovrebbe essere accompagnato da scenari che permettano di:<br />Descrivere il comportamento normale del sistema, esemplificando il requisito con dati di input e output attesi. <br />Individuare i casi limite e descrivere i comportamenti specifici del sistema in questi casi.<br />Definire i criteri, oggettivamente verificabili, di accettazione dell’implementazione del requisito.<br />
  12. 12. BDD: Gli scenari... (2)<br />Gli scenari dei un requisito definiscono i Test Case (come fanno gli Use Case, o il dettaglio sul retro delle Story Card):<br />Calculate average daily price on 3 jobs <br />Creating a WorkOrder with following Jobs:<br /><ul><li>One with duration 5 days and amount 2500
  13. 13. Another with duration 1 days and amount 700
  14. 14. Another with duration 2 days and amount 1200</li></ul>The average daily price should be 550<br />WorkOrder<br />+AverageDailyPrice<br />Job<br />+Duration<br />+Amount<br />
  15. 15. Gherkin Language<br />Il linguaggio «Gherkin» permette di esprimere gli scenari BDD attraverso un DSL compilabile:<br />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<br />Il Linguaggio Gherkin è stato definito nel progetto Cucumber (http://cukes.info/)<br />
  16. 16. DEMO<br />Un esempio di BDD<br />
  17. 17. BDD: Ma come fa...?<br />I tool ci aiutano<br />Ce ne sono tanti e per diversi linguaggi (alcuni più maturi, altri in progress, altri confluiti nei primi o abbandonati!)<br />Le frasi Gherkin diventano eseguibili<br />Generazione automatica del codice <br />Interpretazione da parte del tool<br />Le frasi invocano parti (step) del nostro codice<br />Per convenzione o per altri meccanismi di binding<br />Gli step interagiscono con il Codice di produzione<br />Domain Model<br />Controller MVC<br />Qualsiasi cosa vogliamo testare!<br />
  18. 18. Demo Domain Model<br />WorkOrder<br />SalesAccount<br />Client<br />SalesLine<br />+AverageDailyPrice<br />+Status<br />+FullName<br />+Email<br />+ComapnyName<br />+Name<br />PaymentTranche<br />Job<br />+ExpectedInvoiceDate<br />+Duration<br />+Amount<br />+CompletionState<br />
  19. 19. DEMO<br />BDD con SpecFlow<br />
  20. 20. BDD vs TDD<br />BDD non è un’alternativa a TDD<br />BDD è costruito “sopra” TDD, l’approccio è lo stesso<br />Si inizia con BDD, e sifinisce con TDD!<br />Prima il focus sui requisiti (BDD)<br />Poi sul design e implementazione di dettaglio(TDD)<br />Un ciclo di red-green-refactor di BDD comprende diversi cicli di red-green-refactor di TDD<br />
  21. 21. Benefici di BDD (1)<br />Il punto di partenza è un requisito<br />Focus sul valore per il Business, no gold-plating<br />Meno trasformazioni mentali per tradurre il requisito in codice<br />Obiettivo da raggiungere: green sulla feature<br />L’Ubiquitous Language fluisce naturalmente dal requisito al codice<br />
  22. 22. Benefici di BDD (2)<br />Il requisito fa parte del Codice<br />Il Codice è l’unico artefatto vivente che rappresenta lo stato dell’arte del sistema<br />La documentazione dei requisiti implementati è aggiornata con il Codice<br />Le feature diventano punto di partenza per l’introduzione di nuovi svilluppatori nel progetto<br />Requisiti testati automaticamente<br />Regressione sotto controllo a livello dei requisiti<br />Test di accettazione in gran parte automatizzata<br />Evidenza di implementazione dei requisiti anche per stakeholder meno tecnici<br />
  23. 23. Insignt: Gli effetti di BDD<br />In uno stesso dominio le frasi Gherkin si ripetono<br />I comportamenti sono ricorrenti<br />Si crea uno strato di Codice per manipolare il Domain Model attraverso frasi Gherkin<br />Nasce una nuova grammatica componibile<br />Diventa usa sorta di DSL<br />Un layer di scripting sul Domain Model<br />La produttività per la scrittura di nuove feature e scenari aumenta esponenzialmente<br />
  24. 24. BDD<br />Q & A<br />Grazie!<br />

×