Growing software from examples

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. Customer Test Test Driven Development Domain Driven Design Specification by Example Example Driven Development Acceptance Test Driven Development Behaviour Driven Development

7. http://www.scrumcrazy.com/file/view/ScrumCrazy.com_StoryTestingPatternsSummary3.pdf/391066838/ScrumCrazy.com_StoryTestingPatternsSummary3.pdfhttp://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

23. Don’t hide the context • @Test public void smoker_requires_manual_referral() { • Referral referral = underwriting.process(smoker); • 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); }

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

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

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

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

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

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

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

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