Tdd and-bdd

863 views

Published on

Test driven development and behavior driven development

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

  • Be the first to like this

No Downloads
Views
Total views
863
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Interruptions welcome
  • User story (Connectrix –Mike Cohn)How many of you use user stories or acceptance criteria something like this?Generally we recommend writing these *before* you write the code, yes?
  • Standard waterfall caricatureA lot happens between us writing that requirement and our ability to validate the code that satisfies itWhat’s the difference b/t test & validate? (doing the thing right vs doing the right thing)
  • Top curve (at T0) is a caricature of what I’ve experienced when I delayed testing to the end on a large OMS projectFlat line not really flat – it still trends downwards, but at a much slower and more predictable rateCommon way to stabilize red line – throw armies at it, standardize, add bureacracy, change control = change preventionChaos report – very high rate of failure
  • Who knows what this is?Systems tend to disorder over time
  • Start by removing the altitude – can give false sense of prestige (design > code > test) that gets in the way of experimentation
  • You can do this w/o automation, and in fact those who don’t automate tests actually do thisBut test automation gives you a safety net that scales to catch regression bugs.How many of you are comfortable with test automation?
  • Functional test = tests LOTS of code all at onceIf I hadn’t written this, I would have manually tested the same way (through a browser)
  • Why would we do that?Helps specify what we want before writing the codeOtherwise we might not write the test (encourages automation)
  • Allows you to work in very tiny increments, running tests very frequently
  • I wanted to give you an idea of the granularity we’re talking about…
  • Yes, really. Kent Beck called this “Fake it until you make it.” Sometimes you just write the code, and in this case maybe I would have.
  • Design in the small, percolates to larger design issuesWorks b/c you LISTEN to the tests (too many objects to test something – coupling problem; other object too involved = cohesion problem)Tests automatically give you another user = decreased coupling
  • Took me a year to get here…Doesn’t remove need for QAs, although does allow them to focus on higher value workA lot of people want to test private methods when they start TDD.They’re confusing the intent = it’s not about testingWhite box testing is a design smell
  • Evolutionary design is an alternative to a lot of heavy up front designNot necessarily mutually exclusiveAllows responding to change well. To take a strained analogy, imagine you were the first person building gloves. You could guess where to make it flexible, or you could just make it the same material throughout, which is a lot simpler. In the latter strategy, the areas that need to be flexible will become flexible over time as we bend our joints. Similarly, in evolutionary design, the parts of the code that need to be flexible become flexible b/c they change a lot, as opposed to trying to build that flexibility in. Sometimes, it can still make sense to build in some flexibility -> we’ve built enough gloves by now that we know where to make them flexible. But not all problems are as well understood as glove making
  • A lot of people are uncomfortable with evolutionary design, but I want to emphasize that there’s room for multiple design approaches even on the same project. Classical music relies on a composer carefully crafting a musical piece and directing an orchestra to perform it. Jazz relies on a set pattern of chord transitions and a trust amongst the ensemble to make the most of it.
  • TDD followed religiously prevents you from adding anything not needed
  • Regardless of design approach, this is true, but in evolutionary design, TDD helps enforce a focus on simplicityEssential vs. accidental complexity
  • Enabling change4 = Occam’s razorTension b/t them, esp #2 and #4,which is why priority matters
  • * Just sucked in BAs and QAs into the cycle, and by extension, the customerTests serveas documentationSome pursue BDD within the inner circle. Really just a focus on language and business requirements* Emphasize other role involvement
  • Note that I started this talk off with a test…
  • Tests have a costSpikesStartups?Throw away, one-off codeLearning a language / platform
  • Nothing sucks IQ points faster than coding in front of an audience, so if you don’t think I’m an imbecile yet, wait a few minutes…
  • Tdd and-bdd

    1. 1. TEST-DRIVEN DEVELOPMENTBEHAVIOR-DRIVEN DEVELOPMENT Brandon Byars bbyars@thoughtworks.com
    2. 2. As a software development organization,I want to have more predictability and adaptabilitySo that I can respond to changeGiven a new requirementWhen I write the code for itThen I want to know whether I did the right thing
    3. 3. Analyze Design Code Test Validate
    4. 4. WHY TDD?Productivity Our goal Immature practices Time
    5. 5. dS −− dt ≥0Entropy: It’s the law
    6. 6. Analyze Design Code Test Validate
    7. 7. Analyze Design Code Test Validate
    8. 8. INSIGHT #1: AUTOMATE TEST VERIFICATION CodeAnalyze Design Validate Test
    9. 9. [Test]public void ShouldRouteToEchoAction(){ var response = new HttpRequest("GET”, "http://localhost/RestMvc/echo/hello" ).GetResponse(); Assert.That(response.StatusCode, Is.EqualTo(200)); Assert.That(response.Body, Is.EqualTo("hello"));}
    10. 10. INSIGHT #2: TEST FIRST CodeAnalyze Design Validate Test
    11. 11. INSIGHT #3: JUST ENOUGH CODE TestAnalyze Design Validate Test Code
    12. 12. [TestFixture]public class StackTest{ [Test] public void NewStackShouldBeEmpty() { var stack = new Stack(); Assert.That(stack.IsEmpty()); }}
    13. 13. public class Stack{ public bool IsEmpty() { return false; }}
    14. 14. INSIGHT #4: TDD IS A DESIGN TECHNIQUE Test DesignAnalyze Validate Test Code
    15. 15. INSIGHT #4: TDD IS A DESIGN TECHNIQUE Test CodeAnalyze Validate Test Design
    16. 16. INSIGHT #4: TDD IS A DESIGN TECHNIQUE Test CodeAnalyze Validate Refactoring Design Test
    17. 17. TDD is NOT:• A Testing TechniqueTDD is:• A Design Technique
    18. 18. EVOLUTIONARY DESIGN
    19. 19. “Perfection is achieved, notwhen there is nothing more toadd, but when there is nothingleft to take away.” -Antoine de Saint-Exupery
    20. 20. SimpleAin’tEasy
    21. 21. EVOLUTIONARY DESIGNSimple Design Rules1. Must pass all tests2. Must communicate intent3. No duplication4. Use fewest possible (classes, methods…)
    22. 22. BEHAVIOR DRIVEN DEVELOPMENTThere are only two hard problems in computerscience:• cache invalidation, and• naming things. -- Phil Karlton
    23. 23. Test CodeAnalyze Validate Design Test
    24. 24. INSIGHT #5: TESTS AS COMMUNICATION Specify Test CodeAnalyze Validate Design Test
    25. 25. As a software development organization,I want to have more predictability and adaptabilitySo that I can respond to changeGiven a new requirementWhen I write the code for itThen I want to know whether I did the right thing
    26. 26. private Requirement requirement;[Given(“a new requirement”)]public void GivenANewRequirement(){ requirement = new Requirement(); }[When(“I write the code for it”)]public void WhenIWriteTheCodeForIt(){ requirement.Satisfy(); }[Then(“I want to know .*”)]public void ThenIWantToKnowIfItWorked(){ Assert.That(requirement.IsSatisfied()); }
    27. 27. WHY NOT TDD? Our goalProductivity We’ll never get here… Time
    28. 28. TIC TAC TOE https://github.com/bbyars/TicTacToe

    ×