Improving Design Through Test Driven Development (TDD)
•Als PPTX, PDF herunterladen•
5 gefällt mir•4,839 views
Improving Design Through TDD was presented at the DC Agile Engineering Conference on 12/7/2012 by Sam Brown (@SamuelBrownIV) and Mike McGarr (@jmichaelmcgarr).
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (19)
Mehr von Excella
Mehr von Excella (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Improving Design Through Test Driven Development (TDD)
- 1. Improving Design through Test Driven Development (TDD) Sam Brown @SamuelBrownIV Mike McGarr @jmichaelmcgarr DC Agile Engineering Conference #DCAEC12
- 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
- 5. Test Driven Development Golden Rule of TDD: Never write production code without a failing test http://reddevnews.com/articles/2007/11/01/testdriven-development-tdd.aspx
- 6. TDD improves quality and design http://www.manning.com/koskela2/
- 7. Coupling
- 8. Cohesion
- 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. Bowling Game • Ten Frames per game • 2 rolls per frame • Unless a strike is rolled • Properly calculate Spares • Properly calculate Strikes http://playcasper.com/venues/show/17
- 12. Design Decision
- 14. Design Decision
- 16. Notice the duplication in the tests. Let’s refactor this.
- 20. More duplication
- 22. Design Problem – roll() calculates score Let’s Refactor!
- 24. We need a concept of frames.
- 25. Ugly Code
- 26. Design Decisions • Design client interface • Refactor • Change design without changing behavior • Defer to last responsible moment • Avoids “Big Upfront Design”
- 28. Requested Changes The Bowling game is becoming service oriented! • New Requirement: – Post rolls in real-time
- 29. Collaborator
- 30. Test Doubles • Dummy • Stubs • Fake • Mocks • Spy
- 36. NullPointerException! We need a default implementation.
- 38. Contact Us Sam Brown samuel.brown@excella.com Cute Baby Arrival @SamuelBrownIV 12/20/2012 https://github.com/samueltbrown • J. Michael McGarr • jmcgarr@gmail.com • @jmichaelmcgarr • http://earlyandoften.wordpress.com • DC CI Meetup - http://bit.ly/YRnrwx
Hinweis der Redaktion
- 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)