3. Overview
• TDD to drive out design (live coding)
• Two approaches toTDD
• Bit on architecture and design (if time)
4. TDD for Design
• TDD is supposed to improve your design
• How does that work?
5. Test Driven
Development
• It is a development technique
(rather than a testing technique)
• Incremental (iterative) workflow
• Always write a failing test
first (red)
• Only write the minimum
code to pass the failing test
(green)
• Improve code while all tests
are passing (refactor) http://www.agileapps.co.uk/methodology/continuous.html
6. Worked example
• Order confirmation (think shopping cart)
• Payment has already been taken
• What next?
7. Order Confirmation
• Flag order as Ready to Ship
• Notify customer, e.g. confirmation email
• Arrange shipment
10. 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
11. 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
12. 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)
13. 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
• Use keyboard shortcuts
15. Two TDD approaches
• “Unit testing is out, vertical slice testing is
in” - Sebastian Lambla (2013)
16. 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?)
18. What is “unit”
in “unit test”?
in “unit test”?
• All about isolation, but from what?
• Other classes or methods?
• Other systems (e.g. file system, email,
database)?
• Other tests?
19. 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
21. 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
22. 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
23. 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)
27. Refactor
• We decide to change how we notify
customers (e.g. push notifications)
• We decide to re-shuffle some code...
• How will our two types of test fare?
32. vertical slices: the good
• More expressive tests
• More able to change implementation
without breaking tests
33. 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
35. 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
36.
37. 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
41. 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
