BDD approaches for web development at Agile Testing Days 2009


Published on

The presentation made at Agile Testing Days 2009 by Thomas Lundström

Published in: Technology, Business

BDD approaches for web development at Agile Testing Days 2009

  1. 1. BDD approaches for web development Thomas Lundström, Softhouse Agile testing days Oct 13, 2009
  2. 2. Agenda • What is BDD? • BDD for web applications • BDD + Traditional QA?
  3. 3. BDD • What is BDD?
  4. 4. * BDD aims to bridge the gap bet ween the differing views of computer BDD systems held by Business users and Technologists. It is deeply rooted in the success of TDD and is influenced by ideas like Domain Driven Design. Its focus is on minimizing the hurdles bet ween specification, design, implementation and confirmation of the behaviour of a system. Stakeholders
  5. 5. * Golden triangle bet ween analyst’s requirements, acceptance tests from BDD the test department and the “Done” criteria for a feature used by the developers * Team effort - Analyst - Tester Reqs - Developer/Architect Test Done
  6. 6. * Focus on vocabulary - user stories BDD - acceptance criteria Ubiquitous language! Vocabulary
  7. 7. BDD * Outside-in - onion - use the words of the user, not the programmer * Connection DDD - BDD: use ubiquitous language when specifying the user words * Unit-level tests are still needed Outside-in
  8. 8. Why? BDD * Programmer-driven * Non-user jargon No silver bullet
  9. 9. This is what I find the most interesting with the whole discussion about BDD. Why BDD? - executable specifications - focus on requirements - everything builds upon user stories/ acceptance criteria
  10. 10. User stories As a <role> I want to <perform something> So that <benefit>
  11. 11. User stories - example Context: A guestbook As a public user I want to be able to view messages So that I can see what my friends think
  12. 12. Acceptance criteria Acceptance criteria defines if the soft ware is done One story - Many acceptance criteria Given <pre-requisite state> When <action> Then <outcome>
  13. 13. Acc. criteria - example This is only 2 of the possible acceptance criteria for the story Given that there are 3 messages in the guestbook When I view the home page Then I should see 3 messages Given that there are 3 messages in the guestbook When I view the home page Then I should see 3 messages
  14. 14. (If we work with iterations) BDD Before we do something, we need to agree upon what we should deliver = before stories are pulled into the iteration, we define the acceptance criteria for the story Based on the acceptance criteria and our estimations, we include X number of stories to deliver in the iteration Important: we can’t commit to deliver something unless we know what to deliver = be thorough in splitting a story in acceptance criteria How to use BDD in an iteration?
  15. 15. Tools Ruby: Cucumber, RSpec Java: JBehave .NET: NBehave @deurell,
  16. 16. Focus on process - not tech! Tools Process
  17. 17. Tool architecture Language Runner Glue layer SUT
  18. 18. Tool architecture Language Runner Web-runner HTML
  19. 19. BDD + Web apps All web apps use the same tech to communicate HTML (+ javascript) is the lingua franca for web development
  20. 20. Cucumber + webrat Gherkin Cucumber Cucumber+Webrat HTML
  21. 21. Demo • Domain: Comment functionality (guest book) • Adding • Viewing • (In the future, it’s possible to add moderation, tagging etc)
  22. 22. Current functionality Demo: current functionality • Viewing comments
  23. 23. New iteration Demo: add comments * new feature * new steps * implement steps * implement web app • New feature: adding comments
  24. 24. New iteration • New feature: paging
  25. 25. New iteration • New feature: deleting comments
  26. 26. How to include this into CI environment the regular CI env? Depends on what you run Here: easy with maven2 In .NET land, e.g. msbuild or Ant/Java, let the build script launching the acceptance criteria run Results from the acc criteria run should be output to html so that we know how far we’ve gotten • Run acceptance criteria in the build
  27. 27. Test automation Is there a difference bet ween BDD and the test automation we’ve previously used? - It depends on how the test automation was done - with BDD, we’ve got test automation aligned with (that are) the requirements! Earlier: test automation prone to breakage. Why? - dev changes stuff (button names etc) that test automation uses (fixed by running everything in the build; everyone is in charge of the build, instead of only the test dept) • BDD vs. Test automation? - Requirements churn (we can’t guard from that) - Unstable tools (no guard here either)
  28. 28. Test automation - imperative/declarative
  29. 29. Test automation - imperative/declarative BREAK
  30. 30. Test in a BDD process We use testers to transform high-level stories to “do this, do that” specs. It’s their speciality to find these thngs! • “Quality is not enforced by checking afterwards, but designed into the product” (my interpretation) - James Bach, at a discussion during Øredev 2008
  31. 31. Test in a BDD process Testers can go from performing manual script labour to do more useful stuff - exploratory testing - helping devs & analysts analyse the problem - Performance testing The competence of the testers i.e. translation of abstract Reqs -> hands-on runnables is used when defining acceptance criteria
  32. 32. Thanks! • Thomas Lundström, Softhouse • • Twitter: @thomaslundstrom •