Growing software from examples

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

Heavily influenced by GOOS book:

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/

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

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

Outside-in

http://bddkickstart.com

http://exampler.com

Understandable
Maintainable
Necessary
Granular
Reliable

Understandable

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

Prefer declarative examples

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

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"


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


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

Remember your audience

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

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


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


@Test public void
smoker_requires_manual_referral() {
Referral referral = underwriting.process(smoker);

Assert.assertEquals(Referral.Manual, referral); }

Make data explicit

@Test public void
Customer customer = new Customer(“Joe”, “Smith”,
“12/12/1980”, “Accountant”, “$300,000”, “Yes”,
“No”);

Referral referral = underwriting.process(customer);


Emphasise interesting details

@Test public void
CustomerBuilder builder = new CustomerBuilder();
Customer customer = builder
.withSmokerFlag()
.build();

Referral referral = underwriting.process(customer);


Work collaboratively

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

User / Stakeholder Story

Online subscriptions
In order to increase subscriptions
visitors should be able to
subscribe online with a VISA card

User / Stakeholder Story

VISA subscriptions
In order to increase subscriptions
visitors should be able to
subscribe online with a VISA card

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

"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?

Avoid workflow style

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

Exploratory
and
manual

https://www.ibm.com/developerworks/library/j-aopwork11/TestingPyramid.jpg

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

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

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

Consider costs and benefits

Remove unnecessary examples
Exercise the thinnest slice possible
Automate when viable

Manual
Cost

Automate

Risk

Don’t let example dictate mechanism

Visibility depends on interest not layer.
Insulate examples from technical details.
Acceptance tests not always end-to-end.

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

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

Categorise in multiple dimensions

Faster feedback is better.
Other dimensions are also useful.
Take advantage of partitioning.

Summary

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

Nomenclature

Check
Example
Specification
Test

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

Drive out traceability

-
-
-

Growing software from examples

More Related Content

Similar to Growing software from examples (20)

More from Seb Rose (20)

Recently uploaded (20)

Growing software from examples

Editor's Notes