0
Test Driven Development•   What’s that?•   The good…•   The bad…•   And the ugly…•   How do we begin?•   How do we make it...
What’s that?1. Write a failing test2. Get it to compile.3. Make it pass (do notchange existing code).4. Refactor to remove...
The good…•   Edit and pray vs. Cover and Modify•   Feedback, feedback, feedback!•   Get a living Documentation•   You have...
The good…• It’s highly likely that the code you write will:   – Do what it’s meant to do!   – Keep methods short & simple ...
The bad…• You have to break some habits• You’ll have some development time overhead• You need to keep the test code as cle...
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 ...
How do we begin?1. Understand the problem2. High-level architecture3. Ensure automation for:     –   Writing tests     –  ...
Automation tools• Tests Explorer (VS2012)• MSUnit  – As simple as “Create New Project”  – Generate methods from Unit Tests...
How do we make it sustainable?• Always start by writing a test for the easiest success  case• “Listen” to the tests to get...
Three laws of TDD• First Law You may not write production code  until you have written a failing test.• Second Law You may...
Food for thought…• http://msdn.microsoft.com/en-  us/library/hh212233.aspx• Clean Code A Handbook of Agile Software  Craft...
Tdd
Upcoming SlideShare
Loading in...5
×

Tdd

395

Published on

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

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
395
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Tdd"

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. 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]
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×