Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BDD presentation


Published on

Sharing my BDD presentation @BaltoMSDN group.

Published in: Technology, Education
  • The Recovery Program has made some amazing changes in my life, that I would not have dreamed possible. I have a new-found knowledge on bulimia and have learned so much about myself, the disease and how to take my life back. The support and wisdom from my fellow recoverees is priceless. I’d just feel so alone prior to joining, so opening up to the people in your same shoes and listening to their precious stories and advice has given me this immense strength to recover. ◆◆◆
    Are you sure you want to  Yes  No
    Your message goes here
  • It changed my life. After ten long years of being bulimic I am now bulimia free for six months. All because of this bulimia recovery program. 
    Are you sure you want to  Yes  No
    Your message goes here
  • The 3 Secrets To Your Bulimia Recovery ◆◆◆
    Are you sure you want to  Yes  No
    Your message goes here

BDD presentation

  1. 1. Writing software that matters Temesgen B Meheret (Teme) Senior Software Engineer @ Videology Email:
  2. 2.  Background DDs Why do Projects Fail? Writing Software that matters TDD’s promise and it’s shortcomings BDD’s evolution BDD – Second generation agile methodology Enough Talk, now Code! Summary & Questions Temesgen B Meheret Senior Software Engineer @Videology
  3. 3.  My name is Temesgen but you can call me “Teme” Software Engineer and team lead @Videology Ex-Software Engineer @LCG Plays Ping-Pong Why am I here & not @the Fedexfield for the USA-Brazil soccer match? Writing Software that matters
  4. 4.  How many DDs are you aware of? ◦ DDD, ATDD, TDD, RDD, MDD… How many DD belts do you need before to be a great developer?  Driven – Keeping the right order ◦ HAPPY WIFE – HAPPY LIFE Architecture is Opinion. There are no absolutes. It is really up to us to evaluate and take what applies to our situation. ◦ E.g. Aratkilo building architecture Writing Software that Matters
  5. 5. Adaptation76543 Adaptation210 0 1 2 3 4 5 6 7 8 9 10 11 12 Discussion: Selective Unit Testing – Costs and Benefits by Steven Sanderson Where is our team on this curve for BDD? Writing Software that Matters
  6. 6.  What are the top 3 things that you believe contribute to a failure of a project? Have you ever practiced TDD in your projects? If so, ◦ Where do you start testing? ◦ What did you test? ◦ How much did you rely on your tests (trust) during refactoring? ◦ How effective were your test in terms of detecting bugs? ◦ What did you think was the main intent for writing unit tests? Writing Software that Matters
  7. 7.  Delivering Late or Over Budget ◦ Poor planning, estimation ◦ E.g. Deriving requirements from a running application – sheep’s stomach layers Delivering the wrong thing ◦ Building the product right but not the right product ◦ e.g. Projects shelved after many months of development and investment Unstable in Production ◦ E.g. The morning after Deployment hell Costly to maintain ◦ Code Quality What do you think about asking developers during interviews “How many failed projects have you been part of and what do you think was the cause?” Writing Software that matters
  8. 8. Discussion points: Top-Down vs. Bottom-up, Civil-Engineering projects vs. Software projectsPractical example: LOE flowing down from Solutions Team, Architecture reviews Writing Software that Matters
  9. 9. Software development is all about knowing and delivering WHATMATTERS most to the businessHow do you KNOW WHAT MATTERS?Through effective communication!• Tangible Business Value• Delivered on-time, incrementally• Easy to deploy and manage• Robust in Prod• Easy to understand and communicate In order to achieve this we need to be adaptive in our planning, requirements and design. Regression tests also play a big role to be able to embrace change without fear. Discussion: Nothing replaces People. Writing software that matters
  10. 10. ◦ Clear Communication between Stakeholders  Discussion: Stake holders and their world point of view◦ Constant re-Prioritization owned by the product- owner◦ Immediate feedback at every level◦ Flexibility – Adapting to Feedback  E.g. client’s needs changed, technology difficulties◦ Working on feature-level Writing Software that Matters
  11. 11.  The goal of TDD is specification (Design) and not validation ◦ But we always seem to think of TDD as testing tool. We focus on the verification. IMHO clean code, test assertions and serving as regression suite are all side effects of TDD. ◦ Code by example to implement features but when those examples are done then they act as tests. What went wrong? Where to start? What to test? What not to test? How much test in one go? What to call the tests? How to understand why a test fails? The focus on testing, vague terms, more focus on units than behavior, tests reflect the structural arrangement of the codeProgrammers often think "Im not going to write all those tests.", "Its really simple code, itdoesntneed to be tested", "testing is a waste of time", or "Ive done this (loop/dataretrieval/functionality, etc.)millions of times.". Writing software that matters
  12. 12. • Core Domain Unit testing (Mocking repo) • MVC unit test (Mocking domain and app services) • AppService Unit Test (mocking domain services) • MVC Acceptance TestsOur BDD evolution – Though we had so many unit tests, once we push code to QA, we keep gettingsurprised with scenarios that we never thought about. Then we decided to make QA do test-casereviews at the first week of development. We saw a big value in that which led us to start exploringBDD. Writing Software that Matters
  13. 13.  BDD builds on TDD (Discussion: last year presentation) Stripping out the word test and making test methods sentences Expressive test name is helpful when test fails Behavior is more useful word than test – vocabulary change (Jbehave) Determine the next most important behavior (next thing system doesn’t do) Aha Moment – Requirements are Behavior too! Writing Software that matters
  14. 14.  From Testing To Specification. You write specifications of what your code will have to do - “Specification, not Verification” BDD’s definition: "Its about focusing on the behavior of an application from the point of view of its stakeholders” BDD says you should elevate your mind to a level of behavioral abstraction above the code implementation. BDD ◦ is a second-generation, UT ◦ outside-in, ◦ pull-based, ◦ multiplestakeholder, UT BDD UT ◦ multiple-scale, ◦ high automation, agile methodology. UT“It describes a cycle of interactionswith well-defined outputs, resultingin the delivery of working, testedsoftware.” Discussions: Press releases Writing software that matters
  15. 15.  TDD - BDD DDD – BDD ◦ Focus on the domain and letting it affect the software very much ◦ Ubiquitous language  DDD enables BDD.  BDD helps structure the conversations for DDD ATDD – BDD ◦ "Id like to avoid "BDD is better than TDD because..." or even "BDD is different from TDD (as originally envisioned) because..." TDD is amazing. Its initial conception was to solve exactly what Ive been trying to do with BDD ... Its not the *only* way to come up with good design, and neither is BDD.BDD is about understanding the customers need and letting emerging understanding of that need drive the software write ... always trying to gain greater understanding. But I bet thats what Kent Beck would say if you asked him what TDD was all about." Writing software that matters
  16. 16.  Vision – Outcomes – Feature – Stories – Scenarios User Stories: In order to [business value] As a [role] I want to [some action] Scenarios: Given [context] When I do [action] Then I should see [outcome] Writing Software that Matters
  17. 17.  It is an expression of the customer’s desire It is a Unit of Delivery It focuses on the business value Each story represents part of a feature and belongs to a stake holder (Stake holders belong to a domain)Title (one line describing the story)Narrative:As a [role]I want [feature]So that [benefit]Another flavor:In order to [business value] As a [role] I want to [someaction] Writing Software that Matters
  18. 18.  You define scope using ScenariosScenario 1: TitleGiven [context]And [some more context]..When [event]Then [outcome]And [another outcome]The GWT fragments can be written using Gherkinlanguage. You just create plain text file “.feature”contain a set of scenario definitions. Writing Software that Matters
  19. 19.  Executable Specifications ◦ Each step (scenario) is executable ◦ Code scenarios by example ◦ Examples become code tests and documentation ◦ Scenarios become acceptance tests, regression tests and documentation Writing Software that Matters
  20. 20.  Take only what you can consume YAGNI Any more detail is waste, any less is risk Enough is EnoughAgile ManifestoIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planDiscussion: Extreme is not good Writing Software that Matters
  21. 21.  Anyone who cares about the success of the project is a stake holder ◦ Core stakeholders – the ones with the vision ◦ Incident Stakeholders – the non-functional Writing Software that Matters
  22. 22.  Jbehave (Java) – DanNorth/Chris Matt Rspec (Ruby) Cucubmber (Ruby tool that reads Gherkin) Mspec(Context Specifications) SpecUnit (SetContext,Because of,ItShould) SpecFlow Cucumber Fitnesse Concordion Writing Software that Matters
  23. 23. BDD is more about a mindset rather than thetools. ASP.NET MVC, Specflow, Nunit, Moq, Autofac Writing software that matters
  24. 24.  Easy VS Integration VS Debugger Support Steps can be defined with any .NET language Compiles into a .NET assembly Install SpecFlow.Nunit from NuGet use existing unit-testing frameworks as the runtime for scenario execution Writing Software that Matters
  25. 25. Writing Software that Matters
  26. 26.  The RSpec Book, David Chelimsky, Dan North SPECIFICATION BY EXAMPLE , Gojko Adzik us/magazine/gg490346.aspx, Brandon Satrom ehavior-driven-development-bdd-with- specflow-and-aspnet-mvc/, Steven Sanderson Domain Driven Design, Eric Evans User Stories, Mike Cohen