Your SlideShare is downloading. ×
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply



Published on

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

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

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 test2. Get it to compile.3. Make it pass (do notchange existing code).4. Refactor to removeduplication.5. Repeat.
  • 3. 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
  • 4. 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 
  • 5. 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
  • 6. And the ugly…• TDD is only good when it’s done properly• Coding Ain’t Done ‘Til All the Tests Run*… AND pass!
  • 7. 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.
  • 8. 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.
  • 9. 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
  • 10. 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
  • 11. 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.
  • 12. Food for thought…• 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]