際際滷

際際滷Share a Scribd company logo

Tdd

Download as PPTX, PDF
Cristina Carstea
Cristina Carstea

This document discusses test driven development (TDD). It begins by explaining the basic TDD process of writing a failing test, getting it to compile, making it pass without changing existing code, and then refactoring. It outlines some benefits of TDD like improved code quality and confidence in changes. It also notes some challenges like additional overhead and keeping test code clean. Overall, it argues that while TDD requires proper implementation, it can help produce higher quality code with fewer bugs.

1 of 13
Downloaded 17 times
Test Driven Development Whats that? The good The bad And the ugly How do we begin? How do we make it sustainable? Food for thought
Whats 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.
Tdd
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 Its highly likely that the code you write will: Do what its 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 Youll 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 its done properly Coding Aint Done Til All the Tests Run* AND pass!
Is it worth it?! 100k lines of code => 15 issues 6 months after the release Theres no bug-free product, but there are collateral issues safe nets.
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.
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]

More Related Content

Tdd

  • 1. Test Driven Development Whats that? The good The bad And the ugly How do we begin? How do we make it sustainable? Food for thought
  • 2. Whats 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 Its highly likely that the code you write will: Do what its 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 Youll 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 its done properly Coding Aint Done Til All the Tests Run* AND pass!
  • 8. Is it worth it?! 100k lines of code => 15 issues 6 months after the release Theres 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]