Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Practical TDD Demonstrated
Similaire à Practical TDD Demonstrated (20)
Dernier
Dernier (20)
Practical TDD Demonstrated
- 1. Agile Professionals Network Christchurch Alan Christensen Thanks to our sponsors… Practical TDD Demonstrated
- 2. Preamble • Who am I? • MyTDD journey
- 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
- 8. coding time!
- 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
- 14. Disadvantages • Any problems with this approach?
- 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)
- 26. Code example
- 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
- 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
- 40. Hexagonal Architecture - Alastair Cockburn
- 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