Growing softwarefrom examplesSeb Rose, Claysnow LimitedTwitter:   @sebroseBlog:      www.claysnow.co.ukE-mail:         seb...
Heavily influenced by GOOS book:
They’re called different thingsThe difference is that one is called BehaviourDriven Development – and some people find tha...
est                      Tes        tom   er T                        De    tD    Cus                                     ...
Pattern                     Generally good for                                     Generally bad for                      ...
Outside-in             http://bddkickstart.com
http://exampler.com
Understandable Maintainable  Necessary  Granular   Reliable
Understandable                 http://plus.maths.org/latestnews/sep-dec08/proof/proof.jpg
Maintainable
Necessary
Granular
Reliable
Prefer declarative examplesDeclarative - makes a statement (.)Imperative - makes a command (.)Interrogative - asks a quest...
Imperative vs Declarative StyleFeature: Sign up  Scenario: New user redirected to their own page    Given I am not logged ...
Imperative vs Declarative StyleFeature: Sign up  Scenario: New user redirected to their own page    When I sign up for a n...
Imperative vs Declarative StyleFeature: The entire system  This feature illustrates what can happen when you  take the dec...
Remember your audienceWho 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...
Don’t hide the contextScenario: Increased delivery charges for zip codeGiven my delivery zip code is in AlaskaWhen I go to...
Don’t hide the context    @Test    public voidsmoker_requires_manual_referral()    {     Referral referral = underwriting....
Make data explicit    @Test     public voidsmoker_requires_manual_referral()    {     Customer customer = new Customer(“Jo...
Emphasise interesting details    @Test    public voidsmoker_requires_manual_referral()    {     CustomerBuilder builder = ...
Work collaborativelyCreate 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   subsc...
User / Stakeholder Story   VISA subscriptions   In order to increase subscriptions   visitors should be able to   subscrib...
Acceptance Criteria VISA subscriptions Credit Card Processing Acceptance criteria:  •Must support increase subscriptions I...
"Customers should be prevented from       entering invalid credit card details"Really? So tell me...   • What exactly make...
Avoid workflow styleEvery journey is made from single steps.Workflows are more brittle.A few workflows go a long way.
Exploratory                      and                    manualhttps://www.ibm.com/developerworks/library/j-aopwork11/Testi...
Workflow styleScenario: Happy path for registration and purchaseGiven I am on the homepageAnd I register for an account in...
Workflow styleScenario: Correct postage price for AlaskaGiven I am on the homepageAnd I register for an account in “Alaska...
Focus on a single stepScenario: Correct postage price for AlaskaGiven I am on the checkout pageWhen I select delivery to “...
Consider costs and benefitsRemove unnecessary examplesExercise the thinnest slice possibleAutomate when viable
ManualCost                       Automate                Risk
Don’t let example dictate mechanismVisibility depends on interest not layer.Insulate examples from technical details.Accep...
Make technical tests visibleScenario: High Risk rates for Test PilotsGiven an applicant with occupation “Test Pilot”When t...
Is this end to end?@domain_model@stubbed_underwritingScenario: Applicant with high risk occupationGiven a standard, single...
Categorise in multiple dimensionsFaster feedback is better.Other dimensions are also useful.Take advantage of partitioning.
SummaryExample-based methods are very similar.Minor variations by target audience.Skills are transferable.
NomenclatureCheckExampleSpecificationTest
Seb RoseTwitter:  @sebroseBlog:     www.claysnow.co.ukE-mail:seb@claysnow.co.uk
Backup
Drive out traceability---
Verify dependencies---
Growing software from examples
Growing software from examples
Growing software from examples
Growing software from examples
Growing software from examples
Growing software from examples
Upcoming SlideShare
Loading in …5
×

Growing software from examples

783 views

Published on

Is there any difference between the various example driven approaches to software development?
What are the techniques that are common to all the approaches?
This session answers those questions.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
783
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Scene setting Properties of examples Commonalities between approaches Nomenclature
  • Background &amp; GOOS book
  • TDD red/green/refactor
  • Extended
  • Examples or tests - Liz Keogh
  • Various methods &amp; brief potted history
  • The Bradley document
  • - Try to get a manager to explain what TDD is - summarise / generalise that explanation: we start with a clear goal, before doing the work to achieve it - we can use this same pattern at lots of levels in a software project: if statements in the centre, business goal on the outside
  • Example based Marick
  • Example based properties
  • Living documentation - at all layers - ubiquitous language - single source of truth - required domain knowledge varies
  • Pragmatic ideas - DRY
  • How exhaustive should we be?
  • Single behaviour - granular
  • Must be reliable - cost of failures in time &amp; reputation
  • Commonality 1 - Understandable - Maintainable
  • Declarative vs. Imperative - relate to maintainability and readability - all layers
  • - Understandable - Necessary
  • Background/setup
  • Background/setup
  • Data
  • Data
  • Builders
  • Understandable - Ubiquitous language - Structure of examples Maintainable - Removal of repetition
  • - Credit Liz Keogh for this version of the template - Don&apos;t let the template stop you from thinking! - Anti-pattern: In order to X as a user I want X - &apos;Why&apos; is the cure
  • - Credit Liz Keogh for this version of the template - Don&apos;t let the template stop you from thinking! - Anti-pattern: In order to X as a user I want X - &apos;Why&apos; is the cure
  • - Mention Agile Estimation &amp; Planning / User Stories Applied - Traditional agile - Mike Cohn calls them &apos;conditions of satisfaction&apos; - rules about scope, but not (normally) expressed as examples
  • -Understandable -Maintainable -Granular -Reliable
  • Testing pyramid
  • Background/setup
  • Background/setup
  • Background/setup
  • Consider Cost &amp; benefit - reliable - necessary
  • Cost/risk graph - don’t automate everything - Necessary?
  • Understandable Reliable
  • Testing iceberg
  • Making technical tests visible
  • Mocking/stubbing - only at technical layers? - not interesting to business consumers?
  • Necessary? Granular? Feedback velocity - know the purpose of every example - partition by speed and value
  • Summary - pretty much the same. minor variations depending on target audience
  • Nomenclature - Examples not tests.
  • Testing quadrants - Marick/Hendrickson Is this useful?
  • Decoupling as a matter of course
  • Ports &amp; adaptors
  • Drive Out Traceability - how do we know it’s tested? - how can we be sure it’s only tested once?
  • Verify dependencies - External components - contract &amp; collaboration
  • Growing software from examples

    1. 1. Growing softwarefrom examplesSeb Rose, Claysnow LimitedTwitter: @sebroseBlog: www.claysnow.co.ukE-mail: seb@claysnow.co.uk
    2. 2. Heavily influenced by GOOS book:
    3. 3. They’re called different thingsThe difference is that one is called BehaviourDriven Development – and some people find thatwording useful – and one (or two) is called(Acceptance) Test Driven Development – andsome people find that wording useful in a differentway.And that’s it. Liz Keogh, 2011 http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/
    4. 4. 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 tD ri v Behaviour Driven Developme nt
    5. 5. 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
    6. 6. Outside-in http://bddkickstart.com
    7. 7. http://exampler.com
    8. 8. Understandable Maintainable Necessary Granular Reliable
    9. 9. Understandable http://plus.maths.org/latestnews/sep-dec08/proof/proof.jpg
    10. 10. Maintainable
    11. 11. Necessary
    12. 12. Granular
    13. 13. Reliable
    14. 14. Prefer declarative examplesDeclarative - makes a statement (.)Imperative - makes a command (.)Interrogative - asks a question (?)Exclamatory - shows excitement (!)
    15. 15. Imperative vs Declarative StyleFeature: 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"
    16. 16. Imperative vs Declarative StyleFeature: 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
    17. 17. Imperative vs Declarative StyleFeature: 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
    18. 18. Remember your audienceWho should be able to read the examples?What is their interest in them?Keep things clear.
    19. 19. 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); }
    20. 20. Don’t hide the contextScenario: Increased delivery charges for zip codeGiven my delivery zip code is in AlaskaWhen I go to the checkoutThen I will have to pay the higher delivery charges I will have to pay the higher delivery charges
    21. 21. Don’t hide the context @Test public voidsmoker_requires_manual_referral() { Referral referral = underwriting.process(smoker); Assert.assertEquals(Referral.Manual, referral); }Assert.assertEquals(Referral.Manual, referral); }
    22. 22. Make data explicit @Test public voidsmoker_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); }
    23. 23. Emphasise interesting details @Test public voidsmoker_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); }
    24. 24. Work collaborativelyCreate a ubiquitous language.Use examples to discover the domain.Decompose ruthlessly.
    25. 25. User / Stakeholder Story Online subscriptions In order to increase subscriptions visitors should be able to subscribe online with a VISA card
    26. 26. User / Stakeholder Story VISA subscriptions In order to increase subscriptions visitors should be able to subscribe online with a VISA card
    27. 27. 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
    28. 28. "Customers should be prevented from entering invalid credit card details"Really? So tell me... • What exactly makes someones credit card details invalid? • Can they use spaces? • Should we checksum the digits? • How do we feed back that the details are invalid?
    29. 29. Avoid workflow styleEvery journey is made from single steps.Workflows are more brittle.A few workflows go a long way.
    30. 30. Exploratory and manualhttps://www.ibm.com/developerworks/library/j-aopwork11/TestingPyramid.jpg
    31. 31. Workflow styleScenario: Happy path for registration and purchaseGiven I am on the homepageAnd I register for an account in AlaskaAnd I go to the most popular item pageAnd I add the most popular item to my basketAnd I go to checkoutAnd I select my delivery addressAnd I give valid payment detailsWhen I confirm acceptance of terms and conditionsThen my purchase will be confirmed my purchase will be confirmed
    32. 32. Workflow styleScenario: Correct postage price for AlaskaGiven I am on the homepageAnd I register for an account in “Alaska”And I go to the most popular item pageAnd I add the most popular item to my basketAnd I go to checkoutWhen I select delivery to my home addressThen I have to pay the higher delivery charge I have to pay the higher delivery charge
    33. 33. Focus on a single stepScenario: Correct postage price for AlaskaGiven I am on the checkout pageWhen I select delivery to “Alaska”Then I have to pay the higher delivery charge I have to pay the higher delivery charge
    34. 34. Consider costs and benefitsRemove unnecessary examplesExercise the thinnest slice possibleAutomate when viable
    35. 35. ManualCost Automate Risk
    36. 36. Don’t let example dictate mechanismVisibility depends on interest not layer.Insulate examples from technical details.Acceptance tests not always end-to-end.
    37. 37. Make technical tests visibleScenario: High Risk rates for Test PilotsGiven an applicant with occupation “Test Pilot”When the underwriting engine is invokedThen we will use the “High Risk” rates table we will use the “High Risk” rates table
    38. 38. Is this end to end?@domain_model@stubbed_underwritingScenario: Applicant with high risk occupationGiven a standard, single-life, male applicantBut with a high risk occupationWhen the application is processedThen it will be referred for manual underwriting it will be referred for manual underwriting
    39. 39. Categorise in multiple dimensionsFaster feedback is better.Other dimensions are also useful.Take advantage of partitioning.
    40. 40. SummaryExample-based methods are very similar.Minor variations by target audience.Skills are transferable.
    41. 41. NomenclatureCheckExampleSpecificationTest
    42. 42. Seb RoseTwitter: @sebroseBlog: www.claysnow.co.ukE-mail:seb@claysnow.co.uk
    43. 43. Backup
    44. 44. Drive out traceability---
    45. 45. Verify dependencies---

    ×