TDD In Practice


Published on

Talk I gave at Christchurch Code Camp, August 2013 on test driven development

Published in: Technology, Education
1 Like
  • Be the first to comment

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

No notes for slide

TDD In Practice

  1. 1. TDD in Practice Alan Christensen @christensena
  2. 2. Preamble • Who am I? • MyTDD journey
  3. 3. Overview • TDD to drive out design (live coding) • Two approaches toTDD • Bit on architecture and design
  4. 4. TDD for Design • TDD is supposed to improve your design • How does that work?
  5. 5. Worked example • Order confirmation (think shopping cart) • Payment has already been taken • What next?
  6. 6. Order Confirmation • Flag order as Ready to Ship • Notify customer, e.g. confirmation email • Arrange shipment
  7. 7. coding time!
  8. 8. OrderConfirmation EmailBuilderOrderConfirmer Test Test OrderConfirmation EmailBuilder Fake Email Template Engine Fake
  9. 9. Review • Try to keep the Red Green Refactor discipline • NCrunch is wonderful but costs $$$ • Use test naming to document behaviour • Asserts should match test naming (so typically one assert per test) • Arrange/Act/Assert helps with readability
  10. 10. Review: Mocking • Prefer state based tests • Prefer manual (static) fakes over dynamic • Prefer stubs if using dynamic mocks • Use adapters over untestable code • Use adapters/facades to make application code more expressive of intent
  11. 11. Review:TDD Design • Starting with test helps focus on good API • When test setups (Arrange) get large, it usually tells us we need to factor code into smaller pieces (classes, modules whatever) • Tests help us focus on one small component at a time • Often end up with more general, re-usable components (with rigorous tests)
  12. 12. Lots of tiny classes! • Is this a bad thing? • Best use a DI container • used right they fade into the background • Use IDE code navigation tools • e.g. Go to Definition, Find Usages, Ctrl-T in R# • Use keyboard shortcuts
  13. 13. Disadvantages • Any problems with this approach?
  14. 14. Two TDD approaches • “Unit testing is out, vertical slice testing is in” - Sebastian Lambla (2013)
  15. 15. Two TDD Approaches “A lot of the bad advice about TDD has come from believing that it means testing a module in isolation from other modules, so that you essentially can only have one class under test and you have to have everything else mocked out.” - Ian Cooper (NDC in Oslo 2013 TDD: where did it all go wrong?)
  16. 16. OrderConfirmation EmailBuilderOrderConfirmer Test Test OrderConfirmation EmailBuilder Fake Mail Template Engine Fake
  17. 17. What is a unit test? • All about isolation, but from what? • Other classes or methods? • Other systems (e.g. file system, email, database)? • Other tests?
  18. 18. Isolation approach • Focused test suites, specify behaviour of small units (e.g. classes) • Substitute out all dependencies • Tests inevitably specify implementation details to some extent
  19. 19. OrderConfirmation EmailBuilderOrderConfirmer Test Test OrderConfirmation EmailBuilder Fake Mail Template Engine Fake
  20. 20. isolated: the good • Focused tests allow us to focus on one thing at a time • When tests fail, the source of problem is usually easy to identify • Set ups are small, tests always fast • Encourages well-factored code • Tests relatively easy to write
  21. 21. isolated: the bad • Tends to lock in to a specific implementation • Tests can become a liability, slowing down refactoring • Can lead to focus on implementation details over business value
  22. 22. vertical slice approach • Tests talk to public API only • Tests verify expected results, but not how they are arrived at • Isolation is between tests, not between “units”. • Test suite per feature instead of per class • Still don’t touch external systems (i.e. still fast and stable)
  23. 23. MailSenderOrderConfirmer Test
  24. 24. MailSender OrderConfirmation EmailBuilder OrderConfirmer Test Email Templating Engine
  25. 25. vertical slices: the good • More expressive tests • More able to change implementation without breaking tests
  26. 26. vertical slices: the bad • Harder to drive out your design • Easy to “get lost” in the implementation without close guidance of your tests • Harder to pinpoint bugs when tests fail • Can be more difficult to write tests
  27. 27.
  28. 28. So which to use? • The answer of course: it depends... • Isolation when “discovering” your design • Replace them as appropriate with vertical slice tests • Delete brittle tests! Use code coverage tools to ensure you still have coverage
  29. 29. Other tips • Use “builder” pattern for making test data • Refactor test code like “real” code. Keep it clean! • There is no “right” way to do things
  30. 30. Traditional architecture UI Services DB
  31. 31. Hexagonal Architecture
  32. 32. Hexagonal Architecture - Alastair Cockburn
  33. 33. Links • Source code and link to these slides including this one! • TDD, where did it all go wrong? (Ian Cooper, NDC 2013) • • •
  34. 34. Questions?
  35. 35. Reruns • Repeating this talk 29 August at Christchurch APN Alan Christensen @christensena