Approaching ATDD/BDD
3 likes637 views
This document discusses approaches to acceptance test-driven development (ATDD) and behavior-driven development (BDD). It defines ATDD and BDD, compares them, and outlines best practices like the double loop approach, continuous curation of tests, and ensuring tests are maintained as code. It also discusses test pyramids and different types of tests like unit, integration, acceptance, and how they should be balanced.
Approaching ATDD/BDD
- 1. Approaching ATDD/BDD Compiled By Dhaval Dalal https://dhavaldalal.wordpress.com @softwareartisan
- 2. Note • To bring all this material in one place, I have compiled it from various sources and work done by many people. • References are either explicitly mentioned on the slide and/or in the References section. • This is presented as a journey.
- 3. Testing
- 4. Testing
- 5. Testing
- 6. Testing
- 9. Testing
- 10. Testing
- 11. Testing
- 12. TestQuadrants Functional Acceptance Tests Usability Testing Exploratory Testing System Tests Integration Tests Unit Tests (Design) Non-Functional Acceptance Tests (Performance, Scaling, …) Technology Facing Business Facing CritiqueProduct SupportingtheTeam Automated Manual or Automated ManualAutomated Diagram by Brian Marick
- 13. Double Loop Approach • Underneath AT, follow the Unit Level test/ implement/refactor cycle - TDD cycle. • Start by writing an Acceptance Test (AT) that exercises the functionality to be built. • Failing AT shows that the system does not yet implement that feature. • Passing it - means we are done.
- 14. • Outer loop focuses on meeting customer’s expectations and supporting them. Double Loop Approach • Inner loop focuses on meeting developers’ expectations and supporting them.
- 15. Is BDD == TDD? • TDD captures behaviours and intention - So with BDD. • TDD specs start their journey as a guide and subsequently continue as a sentry preventing regression - So with BDD. • TDD is for low-level requirements (at class/model level), BDD is for high-level requirements (at UI/ Services level) • TDD vocabulary is test-based, BDD vocabulary is English-like. http://neelnarayan.blogspot.in/2010/07/bdd-is-more-than-tdd-done-right.html
- 16. Is BDD == TDD? • TDD captures behaviours and intention - So with BDD. • TDD specs start their journey as a guide and subsequently continue as a sentry preventing regression - So with BDD. • TDD is for low-level requirements (at class/model level), BDD is for high-level requirements (at UI/ Services level) • TDD vocabulary is test-based, BDD vocabulary is English-like. http://neelnarayan.blogspot.in/2010/07/bdd-is-more-than-tdd-done-right.html
- 17. But, BDD != TDD • BDD is mainly about… • Conversation • Collaboration • Devs and QAs collaborating changes the game from finding defects to preventing defects • Devs, BAs and QAs collaborating together helps define executable, verifiable and unambiguous requirements • And With Examples! • Leverage BDD and TDD using the double loop approach
- 18. • Business facing nature demands use of natural language to express intentions. • Express requirements as user stories using the BDD (grammar & structure) collaboratively with the three amigos - BAs, Devs and Testers. • Write user stories (features & scenarios). • Implementation demands use of a general purpose programming language to express test mechanics. • Write code (fixtures) that maps the stories to specs. • Write production code, use TDD to make the specs pass. RSpec
- 19. https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool
- 20. <<preamble>> Feature <<system interaction>> Scenario <<setup repetition>> Background <<data repetition>> Outline <<involved setup>> Inline Tables One feature per file 1..* 0..1 0..1 0..* • Parse Input using • @XStreamConverter, @Transform - Converter • @Delimiter - Split to List • @Format - Dates etc...
- 21. Whats the difference between ATDD & BDD? • ATDD • Focus is on code meeting customer/stakeholder expectations. • Focus is to drive development to deliver the ‘right thing’ • BDD • Focus is on the discovery of stuff we didn’t know about, particularly around the contexts in which scenarios take place. • Enabled Conversations between users and stakeholders
- 22. Does the difference matter? https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/
- 23. Elisabeth responds: As for differences between ATDD and TDR, FTDD, BDD, and STDD, I think we’re all talking about more or less the same thing just using different names. And honestly, I don’t have a strong attachment to any particular name. I do, however, have a strong attachment to some subtle elements of the technique as I describe it. To me, the essential characteristics of ATDD, by whatever name you want to call it, are: . We use test ideas to elicit details from the business stakeholder(s) about their expectations. By proactively discussing test ideas – like boundary conditions or configurations or varying sequences of user actions, etc – we can come to a shared understanding of the business stakeholder’s real expectations for the system instead of having testers file a whole bunch of bugs late in the process. . We distill acceptance criteria into automatable tests expressed in a natural language rather than a programming language. This enables us to completely separate the articulation of expectations from any technical details or dependencies. . We write fixtures or libraries to wire the keywords in the tests to the software under development during implementation. That’s wiring, not translating. And doing it as part of the implementation effort, not attempting to retrofit automation after the code is written. Does the difference matter? http://testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview/
- 24. What can go wrong? • Lack of attention while expressing intent. • Exhaustive acceptance tests. • Absence of continuous curation of tests. • Acceptance tests are solely testers responsibility. • ATs are second-class citizens. Maintainable Acceptance Tests - Agile India 2013 - Jez Humble and Badrinath Janakiraman
- 26. Sustenance Value Effort Low Value High Effort High Value High Effort Low Value Low Effort High Value Low Effort
- 27. The Test Pyramid Technology Facing Business Facing Unit Tests UI Tests Acceptance Tests End-to-End Tests Workflow Tests Journey Tests Feature Tests Integration Tests Adapted from Naresh Jain’s Test Pyramid
- 30. Continuous Curation Features (Acceptance Tests) Journeys (Journey Tests) Extract and evolve
- 31. Continuous Curation Features (Acceptance Tests) Journeys (Journey Tests) Workflows (Workflow Tests) Extract and evolve Extract and evolve
- 32. An Appropriate Perspective • Everyone owns the acceptance tests. • Quality is everybody’s responsibility. • Passing ATs are necessary (but insufficient) for “done”. • Continuous Curation by Devs and QAs together. • Test code is a first-class citizen like production code. Maintainable Acceptance Tests - Agile India 2013 - Jez Humble and Badrinath Janakiraman
- 34. References • Growing Object-Oriented Software - Steve Freeman and Nat Pryce • Maintainable Acceptance Tests - Agile India 2013 - Jez Humble & Badrinath Janakiraman • BDD in Java and Groovy -Venkat Subramaniam • Inverted Test Pyramid and Test Pyramid - Naresh Jain • http://neelnarayan.blogspot.in/2010/07/bdd-is-more-than-tdd-done-right.html • https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related- stuff/ • https://www.infoq.com/news/2011/02/BDD-ATDD • http://testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an- overview/ • https://cucumber.io/blog/2015/12/08/example-mapping-introduction • https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration- tool