1 / 22

Behavior Driven Development in the Real World

Required Slide. SESSION CODE: DPR302. Behavior Driven Development in the Real World. David Starr Pluralsight Instructor ALM Consultant Visual Studio ALM MVP. starr@pluralsight.com Blog: ElegantCode.com @ elegantcoder. In This Session. Conversations About Software

tanisha
Download Presentation

Behavior Driven Development in the Real World

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Required Slide SESSION CODE: DPR302 Behavior Driven Development in the Real World David Starr Pluralsight Instructor ALM Consultant Visual Studio ALM MVP starr@pluralsight.com Blog: ElegantCode.com @elegantcoder

  2. In This Session • Conversations About Software • Expressing Desirements Well • Making Requirements from Desirements • Specification in Context • BDD Tools

  3. Communication is Still a Big Problem • So we use specifications • Use Cases • UML diagrams and models • Numerous large document models • Specification and Requirements • Can be expensive to produce • Good enough often preferred to perfect • Must evolve easily as the software does This isn’t what I thought we agreed on.

  4. Draw It First • Users think at this level • Software has behavior at this level • UI elements give us something to discuss Paper Whiteboards Visio PowerPoint SketchFlow

  5. Expressing Desirements • User Stories represent needed conversations As a <application role> I want <some feature or behavior> So that <I get some benefit> • Scenarios document the conversation took place Given <some initial context> When <this happens> Then <this should be the result> Desirements are things we wish the software did. But it doesn’t. Yet.

  6. A Complete User Story Story: Remove Item From Shopping Cart As aCustomer with Products in my Cart I wantto remove an ItemSo I canchange my mind about buying it Scenario: Multiple Items in CartGiven a Cart with multiple Items in itWhen 1 Item is removedThen the other Items are still in the Cart And the Cart Item Count is correct And the Cart Subtotal reflects the remaining Items

  7. Scenarios Work at Many Levels Customer Domain Concepts UI Element Behavior Input Validation Services Class Behavior Repositories Developer

  8. Making Requirements from Desirements • Executable Specifications Expressing requirements such that they are also tests Because Microsoft Word documents can’t prove software works • Sweet Aromas of Executable Specifications • Meaningful to all interested parties • Unambiguously demonstrate if the requirement is met • Drive out a testable design • Simple

  9. Using Executable Specifications As a I want So that As a I want So that • Make tests that read as Desirements • Tests fail against the SUT • Tests pass against the SUT • Discuss results with customer • Add more and refine as conversations occur Given When Then Given When Then Given When Then Given When Then Given When Then Given When Then

  10. 1, 2, 3 [TestMethod] public void Total_Should_Be_1_When_1_Product_Added() { var cart = new ShoppingCart("TEST"); cart.AddItem(new Product("SKU")); Assert.AreEqual(1, cart.TotalItems); }

  11. Variations on a Theme User Story Structure AAA Context Specification

  12. Sharing Context • Keeps our tests DRY • Reuse existing classes

  13. Context Chaining • Keeps our tests DRY • Can be fragile • Watch Depth of Inheritance

  14. MSpec • Popular Context / Specification library • Love it or hate it • Less to type than rolling your own • May replace existing your existing unit test framework • Includes report generator • Get it here: http://link.pluralsight.com/39um = () =>

  15. StoryQ • Get started with BDD quickly • Too prescriptive for some • Fluent interface for ease-of-use • Compatible with MSTest / NUnit / XUnit • Get it here: http://link.pluralsight.com/3jaf

  16. Other Projects of Interest • StorEvil – Another good .NET BDD libraryhttp://link.pluralsight.com/4n4z • SpecFlow – Another good .NET BDD libraryhttp://link.pluralsight.com/3uwd • Cucumber – BDD for Ruby and IronRubyhttp://link.pluralsight.com/56j7 • Gherkin – A DSL for BDDhttp://link.pluralsight.com/46nm • StoryTeller- .NET native alternative to Fitnessehttp://link.pluralsight.com/5vdn

  17. Summary • Better understand each other before getting started • Ideas of Functionality are Desirements • Desirements express well as User Stories • BDD helps turn Desirements into Requirements • There are many supporting tools to help starr@pluralsight.com Blog: ElegantCode.com @elegantcoder

  18. Required Slide Resources Learning • Sessions On-Demand & Community • Microsoft Certification & Training Resources www.microsoft.com/teched www.microsoft.com/learning • Resources for IT Professionals • Resources for Developers • http://microsoft.com/technet • http://microsoft.com/msdn

  19. Required Slide Complete an evaluation on CommNet and enter to win!

  20. Sign up for Tech·Ed 2011 and save $500 starting June 8 – June 31st http://northamerica.msteched.com/registration You can also register at the North America 2011 kiosk located at registrationJoin us in Atlanta next year

  21. © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

  22. Required Slide

More Related