Test Driven Development• What’s that?• The good…• The bad…• And the ugly…• How do we begin?• How do we make it sustainable?• Food for thought
What’s that?1. Write a failing test2. Get it to compile.3. Make it pass (do notchange existing code).4. Refactor to removeduplication.5. Repeat.
The good…• Edit and pray vs. Cover and Modify• Feedback, feedback, feedback!• Get a living Documentation• You have nothing to lose but your bugs!• Helps you design on the go• Makes ownership transfer much easier• Gives you more confidence in making changes to the code
The good…• It’s highly likely that the code you write will: – Do what it’s meant to do! – Keep methods short & simple – Keep dependencies as weak as possible – Go 100% for Single Responsibility – Not have duplicates – Be protected from invalid input – Have many other qualities that make it awesome
The bad…• You have to break some habits• You’ll have some development time overhead• You need to keep the test code as clean as the production code• You still need the high level designs• You still need more testing
And the ugly…• TDD is only good when it’s done properly• Coding Ain’t Done ‘Til All the Tests Run*… AND pass!
Is it worth it?!• 100k lines of code => 15 issues 6 months after the release• There’s no bug-free product, but there are collateral issues safe nets.
How do we begin?1. Understand the problem2. High-level architecture3. Ensure automation for: – Writing tests – Building – Running Tests4. Write a failing acceptance test = walking skeleton 5. Write a failing unit test6. Make the unit test pass7. Refactor8. Repeat Steps 5-7 until you make the acceptance test pass9. Repeat Steps 4-8 until all the acceptance tests pass.
Automation tools• Tests Explorer (VS2012)• MSUnit – As simple as “Create New Project” – Generate methods from Unit Tests (VS2012)• Microsoft Fakes• Code Coverage Tools• CM Integration
How do we make it sustainable?• Always start by writing a test for the easiest success case• “Listen” to the tests to get rid of uncertainty in the high level design• Always make the tests send correct messages when running• Minimize the implementation overhead: – Only write tests that you would like to read – focused, well named, nicely written – Updating the code => updating test code
Three laws of TDD• First Law You may not write production code until you have written a failing test.• Second Law You may not write more of a test than is sufficient to fail, and not compiling is failing.• Third Law You may not write more production code than is sufficient to pass the currently failing test.
Food for thought…• http://msdn.microsoft.com/en- us/library/hh212233.aspx• Clean Code A Handbook of Agile Software Crafts [Robert Martin]• Working effectively with legacy code [Martin Fowler]• Growing object-oriented software guided by tests [Steve Freeman, Nat Pryce]