This document provides tips and tricks for behavior-driven development (BDD). It discusses what BDD is, including that it is a requirements gathering and team alignment tool. It emphasizes building the right product and building the product right. The document separates problem and solution domains and recommends short user stories that can be developed in two days. It suggests various BDD best practices like separate acceptance criteria from scenarios, deliver features frequently, and observe users interacting with software. Examples are given to illustrate acceptance criteria versus scenarios. The document also discusses testing techniques like separate documentation, unit, and integration tests and avoiding over-automating scenarios. It emphasizes listening to users and releasing feedback.

2. BDD tips & tricks
Carlos Blé - @carlosble

3. What is your understanding BDD?

4. Build the right product
+
Build the product right
Effective requirements gathering technique
Team alignment tool
Set of agile engineering practices

5. Problem Domain Vs Solution Domain
Problem
Solution
Solution
Solution

6. Works for us
Product vision - release vision
Short user stories we can develop in two days.
Vertical user stories.- non-explicit technical stuff
Business valuable examples. - no state
Separate acceptance criteria from scenarios.
Deliver new features every week or two weeks.

7. Direct access to each other to ask
questions face to face at any time.
Hexagonal Architecture (ports & adapters)
Combine Cucumber with other
tools (xUnit, RSpec flavored frameworks)
Mind maps: plan and prioritize
Works for us

8. Specification workshops
Don't focus on automation
Observe the users interact with
our software
Meet the users after every release
Works for us

9. What happens with the GUI?
UI workshops:
3 Roles: UX, Developer, Analyst
User stories often contain
GUI “suggestions” or “guidelines”
GUI should not add unnecessary
constraints

10. Examples Vs Acceptance Criteria
Examples help
to understand
the business,
and remove
ambiguity
But acceptance criteria requires a higher level of
abstraction

11. See the forest for the trees
Acceptance criteria are a quick summary
to help us understand...
● what do we really want?
the desired behavior of the system
● how to demo?
when is the feature done
● documentation:
the implemented behavior

12. As garage organiser
I want to assign jobs to mechanics
To balance the workload in the garage
Acceptance Criteria:
- Jobs are assigned to a single mechanic on a particular
day without specifying the start time
- Jobs have different priorities
- Ongoing jobs can't be assigned from one
mechanic to another
- A finished job can't be assigned to
any other mechanic

13. Background:
“Paco” is a mechanic
Scenario: Assign job to mechanic
Given the job "Change pad brakes" is in the unassigned work queue
And “Paco”'s agenda for tomorrow is empty
When the organizer assigns the job to “Paco” for tomorrow
Then the first thing for him to work on tomorrow is that job
And the job is no longer in the unassigned work queue
Scenario: Prioritize jobs
Given “Paco”'s queue for tomorrow contains "Change oil" & “Inspection”
When the organizer prioritizes the job “Inspection” for “Paco”
Then first thing for him to work on tomorrow is “Inspection”

14. Scenario: Ongoing jobs can't be reassigned
Given that “Paco”'s is working on "Inspection”
When the organizer tries to assign the job to another mechanic
Then the organiser is told that “Paco” is already working on that job
And it remains assigned to “Paco”
Scenario: Finished jobs can't be reassigned
Given that “Paco” is done with job “Change pad brakes”
When the organiser tries to assign it to another mechanic
Then the organiser is told that job is finished and can't be reassigned
Notes:
- Mechanic agenda is stored in table T in the legacy system.
UX Suggestions:
- Drag & drop could be a good metaphor for the assignments

15. Do we need scenarios for this one?
As garage organiser
I need to know what jobs are in the queue
To assign jobs to mechanics
Acceptance Criteria:
- Jobs are in the queue when:
- they are not assigned to a particular mechanic
and the car is in the garage.
- the job doesn't require a pending steering part.

16. Recap
Acceptance criteria specify what should be done
Examples help understand the criteria
Additional information may be useful
When an acceptance criterion is a long line...
When an example doesn't reveal the criterion...
7
E
AC AC
AC
E E
Heuristic

17. Separate types of tests
Documentation tests
- Cucumber
- Nunit with specific tags (attributes):
[Test]
[Specification]
public void …()
●
Triangulation tests
- Integration and unit tests
- Nunit, Webdriver...

18. Automation
Even if we don't automate the scenarios...
Cucumber scenarios don't have to be
integration tests.
Sometimes xUnit/RSpec frameworks are
enough.
Automation often require little changes in the
scenarios...
Avoid complex test setup

19. We love feedback!
Features are not real until they go live and
users embrace them. Don't plan too far away!
Conclusion: listen to your users!
Release Feedback
10