1. Don’t start with login!
BDD for collaboration
and testing
Nate Peterson
@njpetersonpa

2. - BDD overview
- Scenarios
- Practices that helped
- Anti-patterns
- Applying BDD

5. “BDD is a second-generation, outside-in,
pull-based, multiple-stakeholder, multiple-
scale, high-automation, agile methodology.
It describes a cycle of interactions with
well-defined outputs, resulting in the
delivery of working, tested software that
matters.”
--Dan North

6. “BDD’s focus is on the discovery of
stuff we didn’t know about,
particularly around the contexts in
which scenarios or examples take
place. …”
--Liz Keogh

7. “Behaviour-driven-development is
about implementing an application by
describing its behaviour from the
perspective of its stakeholders”
--Dan North

8. “BDD practitioners explore, discover,
define, and drive out desired behavior
of software using conversations,
concrete examples, and automated
tests”
--Matt Wynne

9. Having conversations with domain
experts
and using examples
to gain a shared understanding of the
desired behavior
and discover unknowns

10. Having conversations with domain
experts
and using examples
to gain a shared understanding of the
desired behavior
and discover unknowns

11. Having conversations with domain
experts
and using examples
to gain a shared understanding of the
desired behavior
and discover unknowns

12. Having conversations with domain
experts
and using examples
to gain a shared understanding of the
desired behavior
and discover unknowns

13. Having conversations with domain
experts
and using examples
to gain a shared understanding of the
desired behavior
and discover unknowns

14. Building the right thing
vs.
building the thing right

15. BDD != tools
and
automation
It’s not all about the tools

16. The best tools won’t solve
your customer’s problems if you
don’t know or understand
them

17. If you’re not having
conversations
then you’re not doing BDD
-- Liz Keogh

18. Having conversations
is more important than
capturing conversations
is more important than
automating conversations
-- Liz Keogh

19. Scenarios

20. Scenarios are a way for
describing behavior

21. Given a context
When an event happens
Then an outcome should occur

22. Given Nate purchased a shirt
and the shirt cost $20
When he returns the shirt
Then he should get $20 refunded

23. “…Simply by getting the business users, the
analysts, the testers and the developers to
adopt this vocabulary of
“given/when/then”, they discover that a
world of ambiguity falls away.”
-- Dan North

24. Given a context
When an event happens
Then an outcome should occur

25. Given a context
When an event happens
Then an outcome should occur

26. Given a context
When an event happens
Then an outcome should occur

27. Given Nate purchased a shirt
and the shirt cost $20
When he returns the shirt
Then he should get $20 refunded

28. Is there a context which this event will
create a different outcome?

29. Given Nate purchased a shirt for $20
and he does not have the receipt
When he returns the shirt
Then he should be able to exchange the
shirt for another shirt of the same kind

30. Is this the only outcome that matters?

31. Given Nate purchased a shirt for $20
and the shirt has a hole in it
and he does not have the receipt
When he returns the shirt
Then he should be able to exchange the
shirt for another shirt of the same kind
and the shirt should be processed as
damaged
and the store inventory should be
decremented

32. Scenario
Dos and Don’ts

33. Make the scenarios
user interface
specific
Don’t

34. Given Nate has $20 in his savings account
When he navigates to the transfer screen
and enters $20 into the transfer amount
text box
and clicks the transfer button
then the account balance should be $40
Don’t

35. Make the scenarios
implementation
specific
Don’t

36. Use the language
of the business
Do

37. Address multiple domains
in a single scenario
Don’t

38. Given Nate purchased a shirt
and the shirt cost $20
When he returns the shirt
Then he should get $20 refunded
and the store inventory should be
incremented by 1
Don’t

39. Keep scenarios simple
by focusing on a single domain
at a time
Do

40. Given Nate purchased a shirt
and the shirt cost $20
When he returns the shirt
Then he should get $20 refunded
Given the store as 10 shirts in inventory
When 1 shirt is returned
Then the inventory for that shirt should be 11
Do

41. Add unnecessary
or
irrelevant context
Don’t

42. Keep the context to
just enough
Do

43. Imperative
vs.
declarative
scenarios

44. Given John enters
john.doe@gmail as the username
and
P@55W0rd as the password
When he logs in
Then it should be successful

45. Given John has valid credentials
When he logs in
Then he it should be successful

46. Acceptance criteria
vs.
Scenarios

47. Given Nate purchased a shirt
on December 24th 2014
When he returns the shirt
on April 28th 2015
Then he should be denied a refund

48. Given a shirt was purchased
when it is returned
and the purchase date is older than the
allowed time frame
then it should not be refunded

49. Three Amigos
domain expert – developer – tester

50. domain expert
The person who knows
the business rules

51. developer
The person who thinks in
the solution space

52. tester
The person who thinks in
the problem space

53. No hand-offs

54. The business writes the scenarios and
gives them to the team

55. The developer writes the scenarios
without talking to the team

56. The tester writes the scenarios after
code finished for automated testing

57. Applying BDD

58. People don’t often speak using
Given / When / Then
http://lizkeogh.com/2014/09/01/deriving-gherkin-from-real-conversations/

59. Can you give me an example?

60. What if…?

61. Teams get bored with having
conversations

62. Getting buy-in

63. Benefits of BDD

64. Shared understanding

65. Reduces waste / feedback loops

66. Discover unknowns

67. building the right thing

68. Software that matters

69. @njpetersonpa

70. Resources
Dan North - http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/
Dan North - http://dannorth.net/whats-in-a-story/
Dan North - http://dannorth.net/introducing-bdd/
Liz Keogh - http://lizkeogh.com/behaviour-driven-development/
Liz Keogh - http://www.slideshare.net/lunivore/behavior-driven-development-11754474
Seb Rose - http://www.slideshare.net/sebrose/bdd-history-and-myths