TDD in Practice
Alan Christensen
@christensena
Preamble
• Who am I?
• MyTDD journey
Overview
• TDD to drive out design (live coding)
• Two approaches toTDD
• Bit on architecture and design
TDD for Design
• TDD is supposed to improve your design
• How does that work?
Worked example
• Order confirmation (think shopping cart)
• Payment has already been taken
• What next?
Order Confirmation
• Flag order as Ready to Ship
• Notify customer, e.g. confirmation email
• Arrange shipment
coding time!
OrderConfirmation
EmailBuilderOrderConfirmer
Test Test
OrderConfirmation
EmailBuilder
Fake
Email Template
Engine
Fake
Review
• Try to keep the Red Green Refactor
discipline
• NCrunch is wonderful but costs $$$
• Use test naming to document ...
Review: Mocking
• Prefer state based tests
• Prefer manual (static) fakes over dynamic
• Prefer stubs if using dynamic moc...
Review:TDD Design
• Starting with test helps focus on good API
• When test setups (Arrange) get large, it
usually tells us...
Lots of tiny classes!
• Is this a bad thing?
• Best use a DI container
• used right they fade into the background
• Use ID...
Disadvantages
• Any problems with this approach?
Two TDD approaches
• “Unit testing is out, vertical slice testing is
in” - Sebastian Lambla (2013)
Two TDD Approaches
“A lot of the bad advice about TDD has come
from believing that it means testing a module in
isolation ...
OrderConfirmation
EmailBuilderOrderConfirmer
Test Test
OrderConfirmation
EmailBuilder
Fake
Mail Template
Engine
Fake
What is a unit test?
• All about isolation, but from what?
• Other classes or methods?
• Other systems (e.g. file system, ...
Isolation approach
• Focused test suites, specify behaviour of
small units (e.g. classes)
• Substitute out all dependencie...
OrderConfirmation
EmailBuilderOrderConfirmer
Test Test
OrderConfirmation
EmailBuilder
Fake
Mail Template
Engine
Fake
isolated: the good
• Focused tests allow us to focus on one
thing at a time
• When tests fail, the source of problem is
us...
isolated: the bad
• Tends to lock in to a specific
implementation
• Tests can become a liability, slowing down
refactoring...
vertical slice approach
• Tests talk to public API only
• Tests verify expected results, but not how they
are arrived at
•...
MailSenderOrderConfirmer
Test
MailSender
OrderConfirmation
EmailBuilder
OrderConfirmer
Test
Email Templating
Engine
vertical slices: the good
• More expressive tests
• More able to change implementation
without breaking tests
vertical slices: the bad
• Harder to drive out your design
• Easy to “get lost” in the implementation
without close guidan...
http://www.woodwrightschool.com/ship-in-a-bottle-w-jim/
So which to use?
• The answer of course: it depends...
• Isolation when “discovering” your design
• Replace them as approp...
Other tips
• Use “builder” pattern for making test data
• Refactor test code like “real” code. Keep it
clean!
• There is n...
Traditional architecture
UI
Services
DB
Hexagonal Architecture
http://matteo.vaccari.name/blog/archives/154
Hexagonal Architecture - Alastair Cockburn
Links
• Source code and link to these slides including this one!
https://github.com/christensena/TDDIntro
• TDD, where did...
Questions?
Reruns
• Repeating this talk 29 August at
Christchurch APN
Alan Christensen
@christensena
TDD In Practice
Upcoming SlideShare
Loading in...5
×

TDD In Practice

392

Published on

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

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
392
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "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. http://www.woodwrightschool.com/ship-in-a-bottle-w-jim/
  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 http://matteo.vaccari.name/blog/archives/154
  32. 32. Hexagonal Architecture - Alastair Cockburn
  33. 33. Links • Source code and link to these slides including this one! https://github.com/christensena/TDDIntro • TDD, where did it all go wrong? (Ian Cooper, NDC 2013) http://vimeo.com/68375232 • http://codebetter.com/sebastienlambla/2013/07/11/unit-testing-is-out-vertical-slice-testin • http://martinfowler.com/articles/mocksArentStubs.html • http://alistair.cockburn.us/Hexagonal+architecture
  34. 34. Questions?
  35. 35. Reruns • Repeating this talk 29 August at Christchurch APN Alan Christensen @christensena
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×