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.

Lessons learned with Bdd: a tutorial


Published on

Thinking and Automating with Domain Specific Languages. A tutorial first presented at Test Management Summit, January 2013

Published in: Technology
  • Hello! I can recommend a site that has helped me. It's called ⇒ ⇐ So make sure to check it out!
    Are you sure you want to  Yes  No
    Your message goes here
  • This "special ingredient" makes your relationship his favorite hobby ●●●
    Are you sure you want to  Yes  No
    Your message goes here
  • Without requiring much effort from your part, The Gout Diet guides you step-by-step on how to remove gout quickly and efficiently. For more details: check out the following free video presentation: ▲▲▲
    Are you sure you want to  Yes  No
    Your message goes here
  • Read this heartfelt letter below from Sonasi Samita, a disease-ridden man stricken with kidney failure, diabetes, gout, heart problems, and blindness. He tells his tear-jerking story on how the Demolisher system has totally changed his life! Sonasi says he's convinced that the Demolisher system is God's answer to his prayers! ★★★
    Are you sure you want to  Yes  No
    Your message goes here
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ ◀ ◀ ◀ ◀
    Are you sure you want to  Yes  No
    Your message goes here

Lessons learned with Bdd: a tutorial

  1. 1. Lessons Learned WithBDDThinking and Automating with DomainSpecific LanguagesAlan
  2. 2. Scope● Part 1 - BDD○ BDD Opinionated Overview○ Lessons Learned○ Exercises for BDD with no tools● Part 2 - BDD & Tools○ Cucumber overview○ FitNesse overview○ Custom DSL Overview● Part 3 -○ Q&A + SummariesWarning: pretty much everything in here canbe argued with. BDD emphasisescommunication. So feel free to disagree.
  3. 3. Introduction
  4. 4. The BriefLessons Learned with BDD - Thinking and Automating with Domain Specific LanguagesStarting with the the tools for BDD and Acceptance Testing has become increasingly simple. To learn tools likeCucumber and FitNesse to create tests you can now read books and articles and watch countless videos to help.But using the tools is only part of the battle.Over years of working with Agile teams, and using various tools to help Business Analysts collaborate withDevelopment staff, writing high level tests in a human readable language, Ive learned that most people do notrealise that they are writing a Domain Specific Language.Each of the tools provides a different mechanism for modeling the domain and writing the language. Butfundamentally we are creating a language unique to our domain. And if we do not recognise this, or harness this,then we make our life harder.So in this session I want to look at some of the BDD and Acceptance Testing tool mechanisms e.g. tables orGherkin, with the additional modeling perspective of a high level language that models the domain.Business Analysts are trained in modeling domains. Testers are trained in identifying ambiguity. Developer aretrained in refactoring to domain objects. These skills exist in the development team, we just have to harnessthem.In this session we will explore what this means, and how it changes our approach to writing BDD. This sessiondoes not require access to a computer. Tools will be demonstrated. But tests will be written on paper anddiscussed by the group to explore how to use BDD tools and and languages to more effectively model thedomain.
  5. 5. Alan Richardson● Has used BDD, ATDD, DDD using toolssuch as FitNesse, Cucumber, DomainSpecific Languages● Domains - finance, gambling,pharmaceuticals, media● Has done it well, and badly● Still gets confused by other people so makesup his own models
  6. 6. My BDD Messages● The definition of BDD changes, so youshould own and define it for your domain● Tools are not the answer, but neither iscommunication● I think of BDD as a process of modellingcommunication across multiple domains● Modelling is a domain specific activity, useDSLs and DDD to improve BDD● Expect to make mistakes and receive noexternal instant fit answers(but then I think ofeverything as aprocess)Dont get Hung Up
  7. 7. BDD OpinionatedOverview
  8. 8. BDD relates to communication... but I think it is the worst communicatedthing in Software Development at the momentBDD, ATDD, Specification By Example, BDDesign, ... Development, Real Options, "forCommunication (not development)", DeliberateDiscovery, Feature Injection
  9. 9. Plenty of platitudes for what it is not● "it isnt about testing",● "it isnt the tool",● "it isnt just for the development team"● "if must involve the business"● "it isnt about the how"● BDD isnt ATDD● "it isnt about the automation"● "It isnt just for the business"And most of these are probably true, but dontnecessarily help you understand what to do.
  10. 10. There are universal platitudes of"isness"● It is about communication● It is for bridging the gaps● It brings the business and developmentcloser togetherAgain these are true, but dont help, you do it.
  11. 11. Problems with understanding BDD
  12. 12. The Definition Problem withunderstanding BDD● Definition has changed over the years○ ..D used to be for Development■ because of TDD gaps and flow■ ATDD not using abstraction layers○ now is more like Design, but is still development
  13. 13. The Tool Problem withunderstanding BDD● Same tools used for BDD, ATDD, Spec ByExample○ so what is the differentiator?● BDD is not the tool, but the tool changes theway you do BDD● Tools enforce a syntax which BDD does notrequire○ Gherkin e.g. Given, When, Then○ Tables
  14. 14. The Example Problem withunderstanding BDD● Where are all the good examples?
  15. 15. But we dont get hungup on any problems,we focus on building ashared understandingin our Domain
  16. 16. Building a SharedUnderstanding
  17. 17. Domain Specific LanguageA shared understanding requires ashared language, which we agreeover time.The language should become ubiquitous: inverbal discussion, in written communication, inthe code, in the tests.
  18. 18. Language● Grammar● Syntax● VocabularyA simple model:● Vocabulary and Syntax allow automation● Grammar unites these with domain rules
  19. 19. BDD, ATDD, etc. Nuances over time● BDD, ATDD, Specification by Example etc. -different ways of looking at the sameprocess:○ Moving from desire to reality○ Maintaining as many options as possible○ Allowing us to commit late○ Allow us to experiment○ Building a Shared Understanding○ Checking we are adding value○ Checking we are building it right○ Each name attempts to expose an additionalnuance● Not the same things at all
  20. 20. Not the same things at all but BDD iswinning, because...● When people talk about this they now sayBDD more than any other term● BDD has changed its definition to stay ontop● Modelling is hard, so it is easy to point atother peoples BDD and say this is wrong,then explain the principles again rather thanoffer a right answer
  21. 21. Principles of this BDD thing● Communication● Ubiquitous Language● should - does it? should it? how? when?● Declarative vs Procedural● Concise examples illustrate, explain &explore● Use explanatory text● Model multiple levels● Living spec - review for durability● Review for waste
  22. 22. NuancesofBDD
  23. 23. Some possible lenses or views if Ihave to use the existing terms● DDD (inside out)○ are we using the right language? Are we working atthe right level in the domain?● BDD (outside in)○ what behaviour should this thing exhibit, how do Iknow?● ATDD (what else?)○ what else should it do? how would it handle X? howdid we get it wrong?● Specification by Example (examples?)○ Do we have enough examples? Too many? Theright examples? Will this make sense later? AddsContext● Real Options (commitment)
  24. 24. Gherkin: Given x When y Then zA ubiquitious language (DSL) for analysis, thatmade communication easier to automate:● Feature, Scenario,● Given,○ a particular context (preconditions)● When,○ a particular sequence of events happens● Then,○ observable outcomes● Examples○ A set of examplesWe add theGrammar andVocabulary of theDomain around thisSyntax
  25. 25. Opinionated Summary● I dont care what you call it.● I dont really care how you do it.● But if Im involved, and I see waste orinefficiency, then I use all the lenses to lookat how you model the domain in a DSL andmake suggestions accordingly● Many times I see people using one lenseabove others, and rarely using, orrecognising their use of, a Domain SpecificLanguage
  26. 26. Lessons Learned
  27. 27. Lessons Learned● Dont be tool driven● Agree your domain language● Change your language● Building a DSL is hard● Refine your existing models
  28. 28. Dont be tool driven● When you start, expect to be tool driven● Fitnesse○ Script tables○ Essentially keyword driven automation○ Because the testers cant code○ Reuse of chunks of FitNesse pages○ Refactoring nightmare● Eventually used for○ Database setup and comparison○ A GUI for the data○ But Spreadsheets would have been better (have youever tried to edit FitNesse tables?)
  29. 29. Why not be tool driven?● Youre not fixing your communicationproblem, youre adding a distraction● New tools wont save you● Tool introduces a new layer of abstractionwhich may not help communication● Tool can slow down communication● Tool might impact your options○ may not make change easy○ may not make options easy
  30. 30. Do agree your Domain language● We just wrote down what the BAs said○ including all the inconsistencies● Different nouns to mean the same entity● Different verbs to mean the same process(sometimes a verb, sometimes a verbphrase)
  31. 31. Expect your domain language tochange● Because you will discover and learn more asyou try to express and model the domain● The Domain is not restricted to the business○ e.g. as soon as you commit to building a web app,the language of the web becomes part of yourdomain● Do refactor your language○ if later you decide that visitor is better than a userwho is not logged in then change it - everywhere
  32. 32. Building a DSL is hard● Many people find modelling a DSL hard○ I didnt realise this until we had people try to do it● I think because:○ people are not used to analysing language○ people are not used to building new languages○ people dont want to share/own the language○ people dont feel confident with the written word○ they are overloaded this is new, the tool is new,communication is new○ Gherkin == BDD
  33. 33. Refine your existing models● We kept adding more stuff● Refine your models to remain relevant andrevealing○ move acceptance criteria into functional tests as yougeneralise and expand the scenarios■ e.g. after committing to a web app move the webacceptance criteria from BDD into functional testsand make the BDD more general again○ join scenarios and given when thens into a moregeneric statement - cover detail in lower level tests● Try to keep the BDD small by reworking newparts of the domain into the existing model
  34. 34. How to make DSL constructioneasier?● You can limit the DSL modelling options tothe Vocabulary and the Grammar if you useGherkin
  35. 35. Exercise: Spot andcritique the DSL
  36. 36. What is the DSL here?Given a registered userWhen the customer logs inThen the account holder can view theirpersonal detailsCritique?
  37. 37. Exercise: How might it read?5 mins, make it better● Given a registered user● When the customer logs in● Then the account holder can view theirpersonal details
  38. 38. Debrief - what did you come upwith?5 mins
  39. 39. How might it read?● Are the following:○ Right or wrong?○ Good or Bad?○ Better or worse?○ Does it provide real options○ Supported by examples?
  40. 40. How might it read?● A logged in user can view their accountdetailsCritique?
  41. 41. How might it read?● A logged in user can view their accountdetails○ the language encapsulates the context and event○ this may be harder to automated
  42. 42. How might it read?● Given a logged in user,● when they view their details,● then they can view their detailsCritique?
  43. 43. How might it read?● Given a logged in user,● when they view their details,● then they can view their details○ context encapsulates details so event written at adifferent level,○ Gherkin forces a redundant then■ does it have to be redundant?
  44. 44. How might it read?● Given a logged in user, when the user viewstheir details, then the user can see accountdetails are correctCritique?
  45. 45. How might it read?● Given a logged in user, when the user viewstheir details, then the user can see accountdetails are correct○ provides more of a why○ reveals lack of options■ there exist other ways that a user could checkthe correctness of their account details
  46. 46. Right, Wrong?● Context and Domain specific● Domain has to include:○ Business Domain○ Technical○ Also automation domain - how much of what we saidcould be automated?
  47. 47. Is login an appropriate example?● Is login obvious enough that this is a poorexample?● Do we need communication around login?
  48. 48. Exercise: Dont lettools limit your DSLexpressive power
  49. 49. BDD does not require a toolDo some BDD on the Tracks application.GTD - we think it is going to come back in style.Pretend we are going to create a new versionof the Tracks app and use BDD to help us.
  50. 50. Product Owner (me) Demo of AppDemo of Tracks:- default admin user created during setup- login, logout- create & delete user- amend details, only I can amend admin email- create a next action on review pages: home,project edit, tickler, starred- projects are always personal- CRUD actions on next action, project, context
  51. 51. Exercise: Pick a few of the areas andBDD them● Whatever format you want● I will answer questions as the SME● Small groups● Debrief in 20 mins
  52. 52. Examples: Howincorporating a toolinto the processchanges the optionsaround the DSL forthe domain
  53. 53. Tools: Cucumber JVM
  54. 54. Demo Scope● cucumber-jvm added easily with maven● feature files as resources● run feature files from ide● step definitions in class● regex in annotation to find steps○ supports params● JUnit runner for CI and report creation● IDE support for syntax, quick fix and codecompletion● Gherkin - loose syntax checking● "Scenario Outline" for examples
  55. 55. Lesson Learned: Cucumber-JVM isnot BDD● Cucumber-JVM is an implementation ofCucumber tool● Gherkin is a DSL● Cucumber allows us to map Gherkin text filestatements to code so we can execute aGherkin document● Cucumber means we dont have to write aparser or lexer or the reporting tools● If we dont pull out the elements of the toolthen we cant consider options andalternatives to help us do BDD
  56. 56. Lesson Learned: Dont add all yourcode into step definitions● Tempting to add all test implementationcode into step definitions● But you arent modelling the domain if youdo that, you are using a tool● Build abstraction layers. Model the domains● Creates more options for yourimplementation approach● Supports re-use of automation code acrossmultiple test layers● Because "BDD is not about testing"
  57. 57. Use Multiple Abstraction Layers● Domain● Physical Implementation World○ Page Objects, Page Components, Sites, etc.● Workflows● Feature Files○ Step Definitions● BDDThese help increase flexibility for changing,restrict commitment to fewer layers
  58. 58. Lesson Learned: MultipleAutomation Levels● Functional Testing in conjunction with BDDhelps create multiple abstraction layers○ refactoring○ DRY● Choices about what to model at what level○ e.g. dont have to do everything in BDD tool● In this demo I had existing functional testswhich flushed out the page objects prior tothe Scenario implementation
  59. 59. Lesson Learned: Refactor yourautomation code● Too easy to add new code in, or copy pastebits between steps● Refactor, Refactor, Refactor● Write clean code
  60. 60. About Cucumber-JVM● Java Implementation of Cucumber● Available via maven so easy to add toproject● Annotate Java code with @Given etc. allowssharing steps between scenarios● IDEs (IntelliJ 12) are cucumber aware so:○ can run feature files directly and create stepsAlt+Enter○ code completion and syntax highlighting● JUnit runner for CI● Uses lots of reflection to work
  61. 61. Minimal Gherkin Feature FileFeature:Scenario:* a statement to checkSupports non standardmodellinge.g. non Given, When,Then modelling
  62. 62. Typical Gherkin Feature FileFeature: short description of featureBackground: general infoabout the featureScenario: a scenario descriptionGiven: a given conditionWhen: a particular event happensThen: we can observe that this happened
  63. 63. Lesson Learned: Use the toolfeatures● Dont avoid tool features because you wantthe ability to move between tools○ e.g. cucumber @Before, @After, @tagging, etc.● Using the tool ineffectively can force you tomove away from the tool● You can move between tools usingabstraction layers
  64. 64. Tools: FitNesse
  65. 65. A DSL based on Tables● Cucumber provides a Gherkin parser● FitNesse provides a Table parser● table name○ a scenario● columns○ map on to examples● setter Columns - add data in to fixture● getter Columns? - pull data out of fixture○ if no expected value then these can be used forexecution documentation
  66. 66. Demo● BDD table for login● Code to implement fixture○ reuses our page objects etc.
  67. 67. Pros & Cons Compared withCucumber-JVM● Cons○ Technically more painful to setup○ May deter collaboration if users can edit on serverwithout pairing with dev or test● Pros○ Very rich documentation ability■ but no-one ever seems to use this○ Wiki based for collaboration with users○ Easy to test out new examples from a server deploy○ FitNesse seems to be receiving more love andattention again so keep an eye on it
  68. 68. Tools: Custom DSL
  69. 69. Demo Scope● Test Code● Refactored into Domain and supportingobjects● Readable Tests○ how could it be more readable?● Abstraction layers
  70. 70. Exercise: How could it be morereadable?
  71. 71. When you write your own● Easiest to create abstraction layers thatlook and act like a DSL● Readable code● Supports refactoring, code completion● Take this as far as you need to.○ Can be as complicate or as simple as you like
  72. 72. Is it BDD?● General Question & Discussion
  73. 73. Is it BDD when...● Testers can write tests using the DSL● Business can express intent using the DSL● Moving from business intent to test can bedone collaboratively
  74. 74. Lessons Learned: Constant Reviews● Constantly need to review the DSL code● Patterns and understanding constantlyevolve so need to keep on top andcommunicate across the team● Review to help enforce good programmingpractices
  75. 75. Lessons Learned: GoodProgramming Practices Required● Refactor● Test● DRY● Single Responsibility● Patterns● Use the language well● Leverage libraries where you can
  76. 76. Lessons Learned: Domain Objects● Use DDD lessons and embody Domainobjects in your code● Limit the extent of the objects to avoidoverlapping domains
  77. 77. Final Phase
  78. 78. Q & A
  79. 79. Summary● Dont get hung up on doing it right● You make BDD what it is, if its not workingfor you, change it and fix it● Use all the nuances: DDD, ATDD, Example,Options, TDD to BDD● BDD is not the tools, but the chosen toolschange your Domain and your BDD style● Own your DSL
  80. 80. Self StudyRecommendations
  81. 81. Recommended Web Reading●●●●●●●●
  82. 82. Recommended Books● Domain Driven Design○ by Eric Evans● Growing Object Oriented Software○ by Steve Freeman and Nat Pryce● Specification by Example○ by Gojko Adzic● The Cucumber Book○ by Matt Wynne and Aslak Hellesoy● ATDD by Example○ by Marcus Gartner
  83. 83. Gherkin●●
  84. 84. Cucumber-JVM●●●
  85. 85. FitNesse●●●●
  86. 86. Recommended Listening● DDD interview with Dan North and LizKeogh○
  87. 87. Unused Slides
  88. 88. Some possible Levels to view thecommunication process at● Desire● Contextualised● Examples● Explored○ what did we miss? how did we get it wrong? is itenough?● Implementation (s)Other people use different levels. So do I.