• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Behavior driven development
 

Behavior driven development

on

  • 819 views

Introduction to BDD and an example of BDD

Introduction to BDD and an example of BDD

Statistics

Views

Total Views
819
Views on SlideShare
819
Embed Views
0

Actions

Likes
0
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

    Behavior driven development Behavior driven development Presentation Transcript

    • Behavior Driven Development Writing Software That Matters Tarun SukhaniFriday, May 11, 12 1
    • What is BDD? Behavior Driven Development (BDD) is about implementing an application by describing its behavior from the perspective of its stakeholders. Test Acceptance Test Development Team Driven Driven Business Analysts - Implement Vision Development Behavior Planning - Translate Vision Driven Development Domain Incidental Stakeholders Driven Core Stakeholders - Support Vision Design - Articulate VisionFriday, May 11, 12 2
    • How did BDD originate? Analysis Phase of SDLC was being TDD is not a design tool - it leads overlooked for automation... to emergent design at a granular level... Planning This in turn leads to brittleness Analysis because the structure of the objects we are testing starts to Design take precedence over the interaction and behavior of those Implementation objects. MaintenanceFriday, May 11, 12 3
    • Principles of BDD Enough is enough, or YAGNI (You Ain’t Gonna Need It) Deliver stakeholder value Everything is behavior Outside-In DevelopmentFriday, May 11, 12 4- Enough is enough. We should work to achieve the stakeholder’s expectations but avoid doing more than we need to do. YAGNI principle.• Deliver stakeholder value. There are multiple stakeholders— both core and incidental—and everything we do should be about delivering demonstrable value to them.• It’s all behavior. Just as we can describe the application’s behavior from the perspective of the stakeholders, we can describe low-level code behavior from the perspective of other code that uses it.
    • BDD by example GroupEat An application that allow groups of people to order food online from registered restaurants and have their order emailed or SMSed to the restaurants for pickup or delivery. Features should Highlights Used to group Features are not potential pitfalls only be included features the same as or areas of if they help to together stories! greater concern fulfill this SMART Establish Identify Identify Identify Identify risks vision or outcomes or feature sets or features and and purpose goals themes stories assumptions 1. Able to order from different 1. Restauranteurs should be 1. SMS integration Make group food ordering to 1. User registration restaurants able to create menus 2. Market interest multiple restaurants easy and 2. Order management 2. Keep track of group and 2. Users should be able to convenient 3. Expense tracking individual food expenses see a history of their ordersFriday, May 11, 12 5SMART = Specific Measurable Achievable Relevant Time-boxed
    • GroupEat: Features and Stories Evo he ean t e pE at mu Grou sers to st Barack er, um do yo rder or th u By us ing the o it? allow ir order ak ng e eck th ry. one m ne receivi ch o wo histo ave t eh t case, w fore two In tha nd there a res. r oles, ent featu differ Stakeholder Business Analyst Evo Barack ke them ’s ma tures: two let G reat, rate fea t to ant OK. I w le sepa er, I wan at I Yeah, be ab ac ustom tory so th . oles to 1. As rder his pending both r rder o s to check o check my much I’m I want to w r, history. kn ow ho tauranteu y so that I s r 2 .A s a re rder histo arning. o e k my much I’m Stakeholder Business Analyst chec how knowFriday, May 11, 12 6
    • GroupEat: Scenarios Barack two have ith Kim scena s rio f or the ,I one t He y Kim discuss w g G reat, ustomer i Restauran to kin c r om .50 features volve chec or Item A f otal is $4 in is f order nd my t rant D on . Both ory. One ther you hist 1. If I ay 1 a he o stau nI o rder and t eur. Bo nD fr o m Re 3.00, the r er em C total is $ my orde stom taurant t and I d my the cu he res on f or t an total Day 2 see $7.50 page. Business Analyst Tester shoul d histor y Evo in at rem to filter .I ds me by Barack ak th ose , th re Yeah be able see we can b er into to hat I ly , then ures furth iewing want anges so t ll on OK eat v r date tals that fa ge. two f at include range, to te ran th ories als by dat n a e order specific da er by st tot lt eve w a ithin o like to fi items. order urant, or m. s I’d al t and foo d resta icular ite an part re staur Stakeholder Business AnalystFriday, May 11, 12 7
    • Automating Scenarios The Business Analyst ensures that the stories and respective scenarios use the language of the stakeholders (ubiquitous language) Where it makes sense to do so, scenarios or test cases are automated. Scenarios are made up of individual steps which drive the direction of the development effort. One of the most important characteristics of BDD is that the scenarios are easy to automate and modify yet are still understandable to the stakeholder.Friday, May 11, 12 8
    • Gherkin: DSL for BDD Gherkin is a Domain Specific Language (DSL) for BDD It is i18n compliant and currently supports 35 different languages Gherkin grammar has the following keywords: ★ Feature ★ Background ★ Scenario ★ Scenario outline ★ Scenarios (or examples) ★ Given ★ When ★ Then ★ And (or but) ★ | (which is used to define tables) ★ """ (which is used to define multiline strings) ★ # (which is used for comments)Friday, May 11, 12 9
    • GroupEat: Sample Feature i18n support { # language: en feature tags { @approved @release1.0 feature description { Feature: Customer checks order history In order to monitor spending As a customer I want to check my order history scenario tag { @sprint1 typical scenario { Scenario: Default order history (no filter) @sprint2 edge case scenario { Scenario: Order history with date range filter @sprint2 edge case scenario { Scenario: Order history with restaurant filter @wip @sprint3 edge case scenario { Scenario: Order history with menu item filterFriday, May 11, 12 10
    • GroupEat: Scenario Steps Given: Indicates something that we expect to be true in a scenario; e.g., Given I am logged in as a customer. It is not the same as a precondition. When: Indicates the event in the scenario. Preference is for a single event in a scenario; e.g., When I view order history page Then: Indicates an expected outcome. OK to have more than one (hence the And and But); e.g., Then I should see $7.50 for the order total.Friday, May 11, 12 11
    • Scenario Styles Declarative Imperative Scenario: Default order history (no filter)Scenario: Default order history (no filter) Given I am logged in as a customer Given I am logged in as a customer And I go to the order form And I order Item A from Restaurant B And I select “Restaurant B” from “Restaurants” And I order Item C from Restaurant D And I select “Item A” from “Items” When I go to the order history page And I press “Add Item” Then I should see $7.50 for my order total And I select “Restaurant D” from “Restaurants” And I select “Item C” from “Items” And I press “Add Item” When I go to the order history page Then I should see $7.50 for my order total Tend to be more customized to each scenario. Less More composable, meaning we can generally support verbose, so less amenable to reuse. more scenarios with fewer step definitionsFriday, May 11, 12 12
    • Organizing Features For larger projects or for features with lots of scenarios, we can create subdirectories for each feature, with multiple files in each subdirectory and with cohesive subsets of scenarios in each file We can also choose to organize by feature sets or themes, each in its own subdirectory. features order management order placement order history user registration customer registration restauranteur registration restaurant management customer managementFriday, May 11, 12 13
    • Tag usage Once we get a scenario passing, any subsequent failure is considered a regression. We want some mechanism to fix failing scenarios quickly. Tags allow for this by running only those features or scenarios that we specify. Other uses for tags include identifying scenarios only to be run in a certain environment, representing different sorts of testing, or related to a features set or theme.Friday, May 11, 12 14
    • End with more Gherkin... Background: Lets us write steps that will be invoked before every scenario in a given feature. Multiline Text: For software that uses text files as either input or output. Tables in Steps: When specifying tabular data in steps, usually used with Given or Then. Scenario Outlines: For similar scenarios, we can define an outline for a scenario once, with placeholders for the values that might change from scenario to scenario.Friday, May 11, 12 15
    • GroupEat: Coding Example Ruby on Rails Outside-In Development with Cucumber 1. Start with a scenario. Make user you understand the expected outcomes and how the UI should support a user interacting with the application 2. Run the scenario with Cucumber. This reveals what step definitions need to be defined. 3. Write a step definition for the first step. Run the scenario with Cucumber and watch it fail. 4. Drive out the view implementation. You’ll discover assigned instance variables, controllers, controller actions, and models that the view will need in order to do its job. 5. Drive out the controller implementation, ensuring that the instance variables are properly assigned. With the controller in place, you’ll know what models it needs to do its job. 6. Drive out the models, ensuring that they provide the methods needed by the view and the controller. This typically leads to the fields required for the database. 7. Once you have implemented all the models and the methods you discovered are needed, execute the scenario with Cucumber again to make sure the step is satisfied.Friday, May 11, 12 16