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.

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

7. Testing Testers
Focus
😟

8. Testing Testers
Focus
😟
Testers
Focus
😀

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

25. Inverted Pyramid
UI
Tests
Unit
Tests
Acceptance
Tests

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

28. Continuous Curation

29. Continuous Curation
Features
(Acceptance Tests)

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

33. Breaking Test Quadrants
https://gojko.net/2013/10/21/lets-break-the-agile-testing-quadrants/

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