• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Growing software from examples
 

Growing software from examples

on

  • 1,414 views

This presentation has been given at ScanDev 2013 and XP 2013. It's also going to be given at NDC 2013 later this week. ...

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.

Statistics

Views

Total Views
1,414
Views on SlideShare
1,327
Embed Views
87

Actions

Likes
2
Downloads
0
Comments
0

4 Embeds 87

http://www.linkedin.com 68
https://twitter.com 14
http://ec2-54-243-189-159.compute-1.amazonaws.com 3
http://eventifier.co 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Growing software from examples Growing software from examples Presentation Transcript

    • Growing softwarefrom examplesSeb  Rose,  Claysnow  LimitedTwi$er:                          @sebroseBlog:       www.claysnow.co.ukE-­‐mail:     seb@claysnow.co.uk
    • Test DrivenDevelopmentAcceptance TestDriven DevelopmentBehaviour DrivenDevelopmentDomain DrivenDesignSpecification by ExampleExample DrivenDevelopmentCustomerTest?
    • Heavily influenced by GOOS book:
    • Pattern Generally good for Generally bad forGiven/When/ThenTests that require•a lot of setup OR•easily forgotten setupTests that have a non-obvious triggerTests with few expected outputs• Tests that have unimportant/simple/obvious preconditions• Tests where there are multipledifferent inputs and multipledifferent outputs• Tests where a single Given/When/Then only describes oneof numerous very similar testscenarios•Specification ByExample -Conceptual orConcreteTests that have numerous:Inputs that affect output behaviorOutputs/expected behaviorsTests where it’s important to test a lotof different data scenariosTests where the trigger event issomewhat obviousAny test where it seems like a tablewould be useful to:describe the test better, orhelp explore all of the possibleinputs and outputs for a test.• Simple tests• Tests that are more aboutverifying simple UI behaviorFor instance – “Test that anerror message is displayed whenthe user enters an incorrectpassword.”• Test where there is really onlyone input or preconditionhttp://www.scrumcrazy.com/file/view/ScrumCrazy.com_StoryTestingPatternsSummary3.pdf/391066838/ScrumCrazy.com_StoryTestingPatternsSummary3.pdf
    • 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 adifferent way.And that’s it.Liz Keogh, 2011http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/
    • Outside-inhttp://bddkickstart.com
    • http://exampler.com
    • UnderstandableDesirable propertiesGranularNecessaryMaintainableReliable
    • Understandablehttp://plus.maths.org/latestnews/sep-dec08/proof/proof.jpg
    • Maintainable
    • Necessary
    • Granular
    • Reliable
    • Work collaborativelyCreate a ubiquitous language.Use examples to discover the domain.Decompose ruthlessly.
    • Online subscriptionsIn order to make getting the magazine simplervisitors should be able tosubscribe online with a VISA cardUser / Stakeholder Story
    • VISA subscriptionsIn order to increase subscriptionsvisitors should be able tosubscribe online with a VISA cardAcceptance Criteria•Must support VISA•Does not need to support MasterCard, Switch•...•Customers should be prevented from entering aninvalid credit card number• ...Credit Card ProcessingAcceptance criteria:
    • Really? So tell me..."Customers should be prevented fromentering an invalid credit card number"• What exactly makes someonescredit card number invalid?• Can they use spaces?• Should we checksum the digits?• How do we feed back that the detailsare invalid?
    • http://www.userdrivendev.com/p/user-language-inside-source-code.html
    • http://commitment-thebook.com
    • Remember your audienceWho should be able to read the examples?Keep things clear.What is their interest in them?
    • 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); }
    • Don’t hide necessary 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
    • Don’t hide important data @Test public void smoker_requires_manual_referral() {Referral referral = underwriting.process(smoker);Assert.assertEquals(Referral.Manual, referral); }
    • 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); }
    • 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); }
    • Declarative - makes a statement (.)Prefer declarative examplesExclamatory - shows excitement (!)Interrogative - asks a question (?)Imperative - makes a command (.)
    • Imperative vs Declarative StyleFeature: Sign upScenario: New user redirected to their own pageGiven I am not logged inAnd I visit the homepageAnd 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 pageAnd I should see "Hello, Seb"
    • Imperative vs Declarative StyleFeature: Sign upScenario: New user redirected to their own pageWhen I sign up for a new accountThen I should be taken to my feeds pageAnd I should see a greeting message
    • Imperative vs Declarative StyleFeature: The entire systemThis feature illustrates what can happen when youtake the declarative style too far.Scenario: It worksWhen I use the systemThen it should work perfectly
    • Avoid workflow styleEvery journey is made from single steps.Workflows are more brittle.A few workflows go a long way.
    • https://www.ibm.com/developerworks/library/j-aopwork11/TestingPyramid.jpgExploratoryandmanual
    • 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
    • Workflow style leads to repetitionScenario: 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
    • Focus on a single actionScenario: 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
    • Consider costs and benefitsRemove unnecessary examplesExercise the thinnest slice possibleAutomate when viable
    • CostRiskManualAutomate
    • Verify dependencies“Don’t mock what you don’t own” JoeWalnesTreat 2nd party code same as 3rd party.Contract and collaboration tests.
    • • A stub in a collaboration test mustcorrespond to an expected result in acontract test• An expectation in a collaboration test mustcorrespond to an action in a contract testJ.B. Rainsberger, GOOS mailing list 15 March 2012Contract and collaboration tests
    • Don’t let example dictatemechanismVisibility depends on interest not layer.Remember the intended audience.Acceptance tests not always end-to-end.
    • http://claysnow.co.uk/?p=175315341
    • 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
    • Scenario: 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 underwritingIs this end to end?@domain_model@stubbed_persistence
    • Categorise in multiple dimensionsFaster feedback is better.Other dimensions are also useful.Take advantage of partitioning.
    • Examples are documentationRequirements.Living documentation.Automated regression tests.
    • https://www.relishapp.com/GDS/whitehall
    • NomenclatureTestExampleSpecification
    • http://www.slideshare.net/ehendrickson/the-thinking-tester-evolved
    • http://www.slideshare.net/ehendrickson/the-thinking-tester-evolved
    • NomenclatureTestExampleSpecificationCheck
    • What’s in a name?“... it doesnt take much to see thatthe problems of three little peopledont amount to a hill of beans in thiscrazy world.”Humphrey Bogart “Casablanca”
    • SummaryExample-based methods are very similar.Minor variations by target audience.Skills are transferable.The naming genie is out of the bottle.Collaboration is key.
    • Seb  RoseTwi$er:     @sebroseBlog:       www.claysnow.co.ukE-­‐mail:            seb@claysnow.co.uk