It has steps for getting going with TDD that state:
1. Define the requirements of your application.
2. Familiarize yourself with the feature areas of your application, and decide on a single feature, or the requirements of a feature, to work on.
3. Make a list of tests that will verify the requirements. A complete list of tests for a particular feature area describes the requirements of that feature area unambiguously and completely.
4. File work items for feature requirements and for the tests that need to be written.
5. In Visual Studio, create a project of the type you want. Visual Studio supplies the initial production code in the form of files such as Class1.cs, Program.cs, and Form1.cs, depending on the project type.
6. Define the interfaces and classes for your feature or requirement. You can add a minimum of code, just enough to compile. Consider using the Class Designer to follow this step. For more information, see Designing Classes and Types.
Note
The traditional TDD process does not contain this step. Instead, it advises that you create tests first. This step is included here so that, while creating tests, you can take advantage of two features in Visual Studio 2005 Team System: the GUI design capabilities of the Class Designer, and the automatic test-generation capabilities of Team Edition for Testers.
7. Generate tests from your interfaces and classes. For more information, see How to: Generate a Unit Test.
8. Compare the tests that have been generated with the list of tests you prepared in step 3. Create any tests that are missing from the list you wrote in step 3. For more information, see How to: Author a Unit Test.
While they do bother to make the note about traditional TDD, they are missing out on several major benefits of TDD:
• TDD is design as you go.
• When you use TDD the interfaces and classes you create emerge as an outcome of writing the tests. This helps to keep the code as simple as possible.
• TDD is about writing one test at a time to DRIVE the DEVELOPMENT of the code. This way the developer does not attempt to predict how the code (interfaces+classes) will look when finished, rather code that passes the tests will be written and refactored as needed.
5 comments:
This may seem trite but there are some of us who work on real, mission critical applications where "design as you go" gets you fired.
TDD is about testing - not specific steps. Without a test-driven approach, large systems are hard to maintain. Tests are a must, but your agile approach needs to be more… flexible.
What you forgot is that Team System can make unit test code coverage part of the source control check-in policy. Code coverage reveals that even good unit tests aren't. As a check-in policy I have better (not more) unit tests, reliably.
Were we to walk the letter of the law your blog makes an excellent point. But were we to talk the spirit of TDD, then VSTS will make tests a staple in Microsoft software development shops - at last.
"TDD is about testing - not specific steps. Without a test-driven approach, large systems are hard to maintain. Tests are a must, but your agile approach needs to be more… flexible."
Actually, TDD is about design, not testing. It's not about having 100% test coverage. It's about creating a safety net that can tell you whether changes you are making are affecting other parts of the app.
Don't get me wrong, Test coverage and unit tests in general can be an important part of a quality software project. But that's not what the spirit of TDD is about, and certainly not what my experience with it has been.
Pure test-driven-development, with no legacy code, often results in 80% or 90% test-coverage, sometimes even 100%, WITHOUT EXTRA EFFORT.
Some teams measure the test coverage in order to see what other tests should be written. (Those additional tests are not TDD-tests, because they don't drive the design.)
Microsoft has removed the article. They realized that it was wrong.
Microsoft has replaced Guidelines for Test-Driven Development with a new article that I think hits the mark. :)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/GuidelinesforTDD.asp
Post a Comment