Short description of TDD, its benefits, its drawbacks and how to get an easy start at it.

1. 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

2. What’s that?
1. Write a failing test
2. Get it to compile.
3. Make it pass (do not
change existing code).
4. Refactor to remove
duplication.
5. Repeat.

4. 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

5. 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


6. 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

7. And the ugly…
• TDD is only good when it’s done properly
• Coding Ain’t Done ‘Til All the Tests Run*…
AND pass!

8. 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.

9. How do we begin?
1. Understand the problem
2. High-level architecture
3. Ensure automation for:
– Writing tests
– Building
– Running Tests
4. Write a failing acceptance test = walking skeleton 
5. Write a failing unit test
6. Make the unit test pass
7. Refactor
8. Repeat Steps 5-7 until you make the acceptance test pass
9. Repeat Steps 4-8 until all the acceptance tests pass.

10. 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

11. 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

12. 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.

13. 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]