This document discusses growing software from examples. It suggests that example-based development methods like Behaviour Driven Development (BDD) and Acceptance Test Driven Development (ATDD) are essentially the same, with minor differences in terminology. The goal is to use examples to discover the problem domain and decompose it through collaboration. Examples should be understandable, maintainable, necessary, granular, and reliable.

1. Growing software
from examples
Seb Rose, Claysnow Limited
Twitter: @sebrose
Blog: www.claysnow.co.uk
E-mail: seb@claysnow.co.uk

2. Heavily influenced by GOOS book:

5. They’re called different things
The difference is that one is called Behaviour
Driven Development – and some people find that
wording useful – and one (or two) is called
(Acceptance) Test Driven Development – and
some people find that wording useful in a different
way.
And that’s it.
Liz Keogh, 2011
http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/

6. est Tes
tom er T De tD
Cus velo riven
pm
ent
Domain D
riven
Specif Design
ication
b y Exam
ple
e Dr iven
Exam pl ent
A cceptan ce Test D eve l o pm
en Deve l op m e n t
D ri v
Behaviour
Driven
Developme
nt

7. Pattern Generally good for Generally bad for
Tests that require • Tests that have
•a lot of setup OR unimportant/simple/obvious
•easily forgotten setup preconditions
Tests that have a non-obvious trigger
Tests with few expected outputs
• Tests where there are multiple
Given/When/Th different inputs and multiple
en different outputs
• Tests where a single
Given/When/Then only
describes one of numerous very
similar test scenarios
Tests that have numerous: • Simple tests
Inputs that affect output behavior • Tests that are more about
Outputs/expected behaviors verifying simple UI behavior
Tests where it’s important to test a lot For instance – “Test that an error
Specification By of different data scenarios message is displayed when the
Example - Tests where the trigger event is user enters an incorrect
Conceptual or somewhat obvious password.”
Concrete Any test where it seems like a table • Test where there is really only
would be useful to: one input or precondition
describe the test better, or
help explore all of the possible inputs
and outputs for a test.
http://www.scrumcrazy.com/file/view/ScrumCrazy.com_StoryTestingPatternsSummary3.pdf/391066838/ScrumCrazy.com_StoryTestingPatternsSummary3.pdf

8. Outside-in
http://bddkickstart.com

9. http://exampler.com

10. Understandable
Maintainable
Necessary
Granular
Reliable

11. Understandable
http://plus.maths.org/latestnews/sep-dec08/proof/proof.jpg

12. Maintainable

13. Necessary

14. Granular

15. Reliable

16. Prefer declarative examples
Declarative - makes a statement (.)
Imperative - makes a command (.)
Interrogative - asks a question (?)
Exclamatory - shows excitement (!)

17. Imperative vs Declarative Style
Feature: Sign up
Scenario: New user redirected to their own page
Given I am not logged in
And I visit the homepage
And I follow "Sign up"
And I fill in "Username" with "Seb"
And I fill in "Password" with "password"
And I fill in "Confirm password" with "password"
When I press "Sign up"
Then I should be on my feeds page
And I should see "Hello, Seb"

18. Imperative vs Declarative Style
Feature: Sign up
Scenario: New user redirected to their own page
When I sign up for a new account
Then I should be taken to my feeds page
And I should see a greeting message

19. Imperative vs Declarative Style
Feature: The entire system
This feature illustrates what can happen when you
take the declarative style too far.
Scenario: It works
When I use the system
Then it should work perfectly

20. Remember your audience
Who should be able to read the examples?
What is their interest in them?
Keep things clear.

21. Don’t hide the context
[Test] public void asterisk_should_format_to_em()
{
String expected = "This is <em>em</em> text";
String actual = f.Format("This is *em* text");
Assert.AreEqual(expected, actual); }

22. Don’t hide the context
Scenario: Increased delivery charges for zip code
Given my delivery zip code is in Alaska
When I go to the checkout
Then I will have to pay the higher delivery charges
I will have to pay the higher delivery charges

23. Don’t hide the context
@Test public void
smoker_requires_manual_referral() {
Referral referral = underwriting.process(smoker);
Assert.assertEquals(Referral.Manual, referral); }
Assert.assertEquals(Referral.Manual, referral); }

24. Make data explicit
@Test public void
smoker_requires_manual_referral() {
Customer customer = new Customer(“Joe”, “Smith”,
“12/12/1980”, “Accountant”, “$300,000”, “Yes”,
“No”);
Referral referral = underwriting.process(customer);
Assert.assertEquals(Referral.Manual, referral); }
Assert.assertEquals(Referral.Manual, referral); }

25. Emphasise interesting details
@Test public void
smoker_requires_manual_referral() {
CustomerBuilder builder = new CustomerBuilder();
Customer customer = builder
.withSmokerFlag()
.build();
Referral referral = underwriting.process(customer);
Assert.assertEquals(Referral.Manual, referral); }
Assert.assertEquals(Referral.Manual, referral); }

26. Work collaboratively
Create a ubiquitous language.
Use examples to discover the domain.
Decompose ruthlessly.

27. User / Stakeholder Story
Online subscriptions
In order to increase subscriptions
visitors should be able to
subscribe online with a VISA card

28. User / Stakeholder Story
VISA subscriptions
In order to increase subscriptions
visitors should be able to
subscribe online with a VISA card

29. Acceptance Criteria
VISA subscriptions
Credit Card Processing
Acceptance criteria:
•Must support increase subscriptions
In order to VISA
•Does not need to support MasterCard, Switch
•...
visitors should be prevented from entering
•Customers should be able to
invalid credit card details
subscribe online with
• ... a VISA card

30. "Customers should be prevented from
entering invalid credit card details"
Really? So tell me...
• What exactly makes someone's
credit card details invalid?
• Can they use spaces?
• Should we checksum the digits?
• How do we feed back that the details
are invalid?

31. Avoid workflow style
Every journey is made from single steps.
Workflows are more brittle.
A few workflows go a long way.

32. Exploratory
and
manual
https://www.ibm.com/developerworks/library/j-aopwork11/TestingPyramid.jpg

33. Workflow style
Scenario: Happy path for registration and purchase
Given I am on the homepage
And I register for an account in Alaska
And I go to the most popular item page
And I add the most popular item to my basket
And I go to checkout
And I select my delivery address
And I give valid payment details
When I confirm acceptance of terms and conditions
Then my purchase will be confirmed
my purchase will be confirmed

34. Workflow style
Scenario: Correct postage price for Alaska
Given I am on the homepage
And I register for an account in “Alaska”
And I go to the most popular item page
And I add the most popular item to my basket
And I go to checkout
When I select delivery to my home address
Then I have to pay the higher delivery charge
I have to pay the higher delivery charge

35. Focus on a single step
Scenario: Correct postage price for Alaska
Given I am on the checkout page
When I select delivery to “Alaska”
Then I have to pay the higher delivery charge
I have to pay the higher delivery charge

36. Consider costs and benefits
Remove unnecessary examples
Exercise the thinnest slice possible
Automate when viable

37. Manual
Cost
Automate
Risk

38. Don’t let example dictate mechanism
Visibility depends on interest not layer.
Insulate examples from technical details.
Acceptance tests not always end-to-end.

40. Make technical tests visible
Scenario: High Risk rates for Test Pilots
Given an applicant with occupation “Test Pilot”
When the underwriting engine is invoked
Then we will use the “High Risk” rates table
we will use the “High Risk” rates table

41. Is this end to end?
@domain_model
@stubbed_underwriting
Scenario: Applicant with high risk occupation
Given a standard, single-life, male applicant
But with a high risk occupation
When the application is processed
Then it will be referred for manual underwriting
it will be referred for manual underwriting

42. Categorise in multiple dimensions
Faster feedback is better.
Other dimensions are also useful.
Take advantage of partitioning.

43. Summary
Example-based methods are very similar.
Minor variations by target audience.
Skills are transferable.

44. Nomenclature
Check
Example
Specification
Test

45. Seb Rose
Twitter: @sebrose
Blog: www.claysnow.co.uk
E-mail:seb@claysnow.co.uk

46. Backup

50. Drive out traceability
-
-
-

51. Verify dependencies
-
-
-