Improving Design through TDD


Published on

Sam Brown and Mike McGarr presented "Improving Design through TDD" at the 2012 DC Agile Engineering Conference

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Mike
  • (Mike)Fast – runs in less than 1/10 secondIndependent– test one thing only (single assert)Repeatable – reliably repeatable (no external dependencies)Self-Verifying – red or green…no human interpretationTimely – test written before production code
  • (Sam)Red-Green-RefactorRefactoring – changing code without changing behaviorGolden Rule of TDD: Never write production code without a failing test
  • (Sam)Unit testing alone helps focus on qualityQuality only unit testing has limitsTDD allows developers to also improve design, increasing the value of testsLasseKoskela calls this the law of two plateausTransition to Advantage:Commonly understood advantage: QualityLess known: Improving DesignAdditional Voice Track: As we approach 100% coverage, effort to achieve small increases in coverage are greater than the value returned
  • (Mike)Metrics of maintainability:Coupled Elements – A change in one forces a change in another (want loose coupling)Inheritance vs. Interface
  • (Sam)Coherence – a measure of whether an element’s responsibility form a meaningful unit.Do one thing only-Animation to show first class, then divided out- What the heck is ‘coherence’???
  • SRP – do one thing only (coherence)OCP – objects should be open for extension/closed for modificationLSP – objects should be replaceable by sub-types (design by contract)ISP – many client specific interfaces are better than one multi-purpose oneDSP – depend on abstractions and not concrete classes (dependency inversion)
  • Calculate score for bowlsUnderstand sparesUnderstand strikes
  • Test to ensure JUnit is working
  • First design decision
  • Only going to talk about Stubs and MocksDummy – objects that are passed but never usedStubs – pre-canned answers to method callsFake – scaled down version of production (InMemoryDB)Mocks – set expectationsSpy – records information passed to it
  • Introduce a new test
  • 1. ImportMockito (discuss what it is)2. Declare interface and use Mockito to mock3. Define dependency injection of RollNotificationService4. Then,…roll5. Verify that the mock RollNotificationService’s publish method was called once
  • We create the new interfaceTest still failsIf we look at the unit test, the Game object needs to be updated
  • We now update the Game with dependencySOLID – Dependency InversionTest still failsOur interface needs a new publish method
  • We add method to interfaceTest still failsWe’ve resolved all compilation errorsThe roll() method never calls publish!The error we get is different…not an assertion
  • Add the call to the serviceTest fails! (Huh?!)All other tests fail due to NullPointerException(Emphasize how powerful this fast feedback is on regressions)
  • Created a new default implementation(would likely not do this in production…let me know if we should change to another type or demand)
  • Improving Design through TDD

    1. 1. Improving Design throughTest Driven Development (TDD) Sam Brown @SamuelBrownIV Mike McGarr @jmichaelmcgarr DC Agile Engineering Conference #DCAEC12
    2. 2. About Us Sam Brown Mike McGarr• 11 years software engineer • 11 years software engineer• DevOps Evangelist at Excella • Directory of DevOps for• Certified Scrum Master Blackboard Learn• Puppet Certified • Founder of the DC Professional Continuous Integration, Delivery and Deployment Meetup
    3. 3. Types of Tests
    4. 4. Unit TestsFastIndependentRepeatableSelf-VerifyingTimely
    5. 5. Test Driven Development Golden Rule of TDD: Never write production code without a failing test
    6. 6. TDD improves quality and design
    7. 7. Coupling
    8. 8. Cohesion
    9. 9. Object Oriented Design Principles Single responsibility principle (SRP) Open/close principle (OCP) Liskov substitution principle (LSP) Interface segregation principle (ISP) Dependency inversion principle (DSP)
    10. 10. Bowling Game• Ten Frames per game• 2 rolls per frame • Unless a strike is rolled• Properly calculate Spares• Properly calculate Strikes
    11. 11. DesignDecision
    12. 12. DesignDecision
    13. 13. Notice the duplication in the tests. Let’s refactor this.
    14. 14. More duplication
    15. 15. Design Problem – roll() calculates scoreLet’s Refactor!
    16. 16. We need a concept of frames.
    17. 17. Ugly Code
    18. 18. Design Decisions• Design client interface• Refactor • Change design without changing behavior• Defer to last responsible moment • Avoids “Big Upfront Design”
    19. 19. New Requirements!
    20. 20. Requested ChangesThe Bowling game is becoming service oriented!• New Requirement: – Post rolls in real-time
    21. 21. Collaborator
    22. 22. Test Doubles• Dummy• Stubs• Fake• Mocks• Spy
    23. 23. NullPointerException! We need a default implementation.
    24. 24. Contact UsSam Cute Baby Arrival@SamuelBrownIV 12/20/2012 • J. Michael McGarr • • @jmichaelmcgarr • • DC CI Meetup -