This presentation has been given at ScanDev 2013 and XP 2013. It's also going to be given at NDC 2013 later this week. The key message is that there is a huge amount in common between the various example-based development techniques. The differences are minor and mainly due to the background of the technique and its intended audience.

1. Growing software
from examples
Seb
Rose,
Claysnow
Limited
Twi$er:
@sebrose
Blog:
www.claysnow.co.uk
E-­‐mail:
seb@claysnow.co.uk

2. Test Driven
Development
Acceptance Test
Driven Development
Behaviour DrivenDevelopment
Domain Driven
DesignSpecification by Example
Example Driven
Development
CustomerTest
?

3. Heavily influenced by GOOS book:

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

7. 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/

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

9. http://exampler.com

10. Understandable
Desirable properties
Granular
Necessary
Maintainable
Reliable

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

12. Maintainable

13. Necessary

14. Granular

15. Reliable

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

17. Online subscriptions
In order to make getting the magazine simpler
visitors should be able to
subscribe online with a VISA card
User / Stakeholder Story

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

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

20. http://www.userdrivendev.com/p/user-language-inside-source-code.html

21. http://commitment-thebook.com

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

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

24. Don’t hide necessary 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

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

26. 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);
}

27. 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);
}

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

29. 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"

30. 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

31. 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

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

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

34. 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

35. Workflow style leads to repetition
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

36. Focus on a single action
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

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

38. Cost
Risk
Manual
Automate

40. Verify dependencies
“Don’t mock what you don’t own” JoeWalnes
Treat 2nd party code same as 3rd party.
Contract and collaboration tests.

41. • A stub in a collaboration test must
correspond to an expected result in a
contract test
• An expectation in a collaboration test must
correspond to an action in a contract test
J.B. Rainsberger, GOOS mailing list 15 March 2012
Contract and collaboration tests

42. Don’t let example dictate
mechanism
Visibility depends on interest not layer.
Remember the intended audience.
Acceptance tests not always end-to-end.

43. http://claysnow.co.uk/?p=175315341

44. 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

45. 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
Is this end to end?
@domain_model
@stubbed_persistence

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

47. Examples are documentation
Requirements.
Living documentation.
Automated regression tests.

48. https://www.relishapp.com/GDS/whitehall

49. Nomenclature
Test
Example
Specification

50. http://www.slideshare.net/ehendrickson/the-thinking-tester-evolved

51. http://www.slideshare.net/ehendrickson/the-thinking-tester-evolved

52. Nomenclature
Test
Example
Specification
Check

53. What’s in a name?
“... it doesn't take much to see that
the problems of three little people
don't amount to a hill of beans in this
crazy world.”
Humphrey Bogart “Casablanca”

54. Summary
Example-based methods are very similar.
Minor variations by target audience.
Skills are transferable.
The naming genie is out of the bottle.
Collaboration is key.

55. Seb
Rose
Twi$er:
@sebrose
Blog:
www.claysnow.co.uk
E-­‐mail:
seb@claysnow.co.uk