• Save
BDD in DDD
Upcoming SlideShare
Loading in...5
×
 

BDD in DDD

on

  • 729 views

Behavior Driven Development in Domain Driven Design

Behavior Driven Development in Domain Driven Design

Statistics

Views

Total Views
729
Views on SlideShare
721
Embed Views
8

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 8

http://lanyrd.com 5
http://www.feedspot.com 2
http://feeds.feedburner.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

BDD in DDD BDD in DDD Presentation Transcript

  • BDD
    {
    Bring(UserStories)
    .SharedWith(DomainExpert)
    .Into(YourCompiledCode);
    }
    Omid Ehsani
  • Grazie!
  • Dal Dominio al Codice (1)
    Domain
    Abstraction
    Model
    Realization
    Design
  • 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?
  • Gli aspetti di Design (1)
    Aspetti Strutturali
    Bounded Contexts
    Aggregates (e altri building blocks)
    Static Diagrams
    Design Patterns
  • Gli aspetti di Design (2)
    Aspetti Comportamentali
    User Stories / Use Cases
    Test Cases
    Dynamic Diagrams
    Automated Testing (TDD)
  • DEMO
    TDD nel Codice
  • 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
  • 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.
  • 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
  • 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.
  • BDD: Gli scenari... (2)
    Gli scenari dei un requisito definiscono i Test Case (come fanno gli Use Case, o il dettaglio sul retro delle Story Card):
    Calculate average daily price on 3 jobs
    Creating a WorkOrder with following Jobs:
    • One with duration 5 days and amount 2500
    • Another with duration 1 days and amount 700
    • Another with duration 2 days and amount 1200
    The average daily price should be 550
    WorkOrder
    +AverageDailyPrice
    Job
    +Duration
    +Amount
  • 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/)
  • DEMO
    Un esempio di BDD
  • 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!
  • Demo Domain Model
    WorkOrder
    SalesAccount
    Client
    SalesLine
    +AverageDailyPrice
    +Status
    +FullName
    +Email
    +ComapnyName
    +Name
    PaymentTranche
    Job
    +ExpectedInvoiceDate
    +Duration
    +Amount
    +CompletionState
  • DEMO
    BDD con SpecFlow
  • 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
  • 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
  • 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
  • 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
  • BDD
    Q & A
    Grazie!