The document discusses Acceptance Test Driven Development (ATDD) and its relationship with Test Driven Development (TDD), highlighting the essential rules and processes for both methodologies. It outlines the importance of writing acceptance criteria before coding, along with the benefits and challenges associated with ATDD, such as improved planning and team alignment. Additionally, it provides examples of user login scenarios and emphasizes the importance of clarity and simplicity in scenario writing.

1. Acceptance
Test
Driven
Development

2. What is the difference
with
TDD?

4. Unit Tests

5. One class
One method

6. No dependencies
(mocks)

7. Core of TDD

8. Rules of TDD
http://bit.ly/1fnUgW6

9. You are not allowed to
write any production
code unless it is to make a
failing unit test pass.
Rule #1

10. You are not allowed to
write any more of a unit
test than is sufficient to
fail; and compilation
failures are failures
Rule #2

11. You are not allowed to
write any more
production code than is
sufficient to pass the one
failing unit test
Rule #3

12. 1. Unit Test First (no excuse)
2. Minimal test code
3. Minimal production code
Summary

13. More than
one class

14. Communication
between
components

15. Acceptance tests

16. What is the limit
of TDD?

17. Expectations

18. Reality

19. What happened?

20. End to end

21. Black box testing

22. Works with
Legacy Code

23. Works with
New Code

24. Works with
-40!!!

25. Core of BDD
(also called ATDD)

26. Narrowing the gap

27. Fail Fast

28. Where can we fail?

29. Analysis?
Implementation?
QA?
Deploy?
Demo?

30. Acceptance Criteria
First

31. Rules of ATDD

32. You are not allowed to
write any unit test code
unless it is to make a
failing acceptance
criteria pass.
Rule #1

33. You are not allowed to
write any more of one
acceptance criteria that
is sufficient to fail
Rule #2

34. Define your acceptance
criteria as a group
Rule #3

35. 1. Acceptance Criteria First
2. Minimal TDD
3. Define the criteria as a
group
Summary

36. ATDD Flow
Write a Criteria
Pass?
TDD Cycle
NOYES

37. Feature Driven
Benefits

38. Adding value on
every step
Benefits

39. High Quality
Benefits

40. Regression
Testing
Benefits

41. Writing Scenarios
(Acceptance Criteria)

42. A User Story
may have multiple paths

43. Each path represents a
possible scenario

44. Each scenario is a
sequence of steps

45. Each scenario is a
sequence of steps

46. Write scenarios for a user
login story
Post-It
&
Sharpie!
Exercise

47. Scenario: Valid credentials
Given I have valid credentials
When I login to the movie library
Then I see my dashboard
User Login

48. Scenario: Invalid credentials
Given I don’t remember my password
When I login to the movie library
Then I see a message to recover my
password
User Login II

49. Scenario: Using google Oauth
Given I have an account with google
When I login choosing google
Then I can see my dashboard
User Login II

50. Gherkin DSL

51. Given
The state of the application
in order for the scenario to
run successfully

52. When
The action that has to be
completed in the current
scenario

53. Then
The acceptance criteria
that the scenario uses in
order to ensure success

54. Rewrite one of your
scenarios using
Given, When, Then, And
Post-It
&
Sharpie!
Exercise

55. Guidelines

56. _ _ _ _ _ _ _ _ _ ?
Scenario: Everything is awesome
Given the application is setup
When I want to use some projects
Then I should be able to load data
And have a great user experience
but no bugs should appear

57. Scenario: Redirect user to originally requested page
Given a User "dave" exists with password "secret"
And I am not logged in
When I navigate to the home page
Then I am redirected to the login form
When I fill in "Username" with "dave"
And I fill in "Password" with "secret"
And I press "Login"
_ _ _ _ _ _ _ _ _ ?

58. Scenario: List all projects
Given I'm logged in
And I have some projects stored
When I list all the projects
Then I should see all of them
_ _ _ _ _ _ _ _ _ ?

59. Complexity
How can we estimate a
feature using scenarios?

60. COMPLEX ∝ #SCENARIOS
0
1
2
4
5
6
7
Simple Medium Complex WTF?
Scenarios
Complexity

61. COMPLEXITY ∝ CLARITY
Too many steps
Too long to write
Nobody can understand it

62. Scenario Order
What should go first?
List movies or create
movies?

63. Size Matters
How many scenarios per
story?

64. Make every story around the
same size
•One or two scenarios most
•Or break it down
Recipe - Step I

65. Time limit (days) to each
feature
•After one or two days
•break it down
Recipe - Step II

66. Choose simplest story-
scenario to flush out
implementation and discover
new requirements
Recipe - Step III

67. Demo

68. Summary

69. Benefits
• Easier planning
• Discovers functionality
and complexity
• No particular skill
required
• Easy Adoption
• Puts the whole team
on the same page
• Simplifies QA process
• Narrows the gap
between expectations
and actual
implementation

70. Challenges
•Requires discipline
•Owner must participate
•Roles get blured
•QA changes drastically

71. Thank you!

72. amir@barylko.com
@abarylko
http://bit.ly/abarylkop

75. Photo Credit
• Under http://creativecommons.org/licenses/by/2.5/
• Joe Cheng, DSC_7820-01, http://flic.kr/p/2Zt2u
• Bill Ward, Derek Schin's Trucks 1, http://flic.kr/p/m5L5S
• Jeremy Keith, Roast beef, http://flic.kr/p/TKUz
• Rob Campbell, Field of daisies, http://flic.kr/p/6QJjU4
• Karin Dalziel, The Thinker, http://flic.kr/p/4UYArc
• Under http://creativecommons.org/licenses/by-sa/3.0/us/
• Derick Bailey, SOLID Motivational Posters, http://bit.ly/17aVaHg

76. Photo Credit 2
• How to write good code, http://xkcd.com/844/
• Understanding flow charts, http://lifehacker.com/5909501/how-to-
choose-the-best-chart-for-your-data