I got a question about TDD and unit test using Visual Studio 2008 Pro. One of the TDD requirements reads something like "All tests should fail initially when there is no coding yet!" However, when I generate a test project from VS 2008 Pro, all tests can pass before any coding. Do I have to add code to the test project, in order to make the test fail initially? Or am I missing something here?
Yes, I need to write some code to meet the TDD requirement. I don't want to write code every time I generate a TDD unit test. I think I have a solution here, i.e., adding the minimum TDD code to a new test project template called "TDDUnitTest".
Basically, to meet the specific TDD requirement under discussion, I would create a sample unit test project that handles two initial cases:
1) Check the app.config file and see if the class being tested has been coded. In order to do that, you need to add a key to the config file and set it to false initially. Of course, some more intelligent alternative can be implemented if you feel like to.
2) As Ravi suggested in his message below, have each of the unfinished methods throw an "unimplemented" exception. Add a handler to the test code to capture this and fails aumatically.
After you have the above minimum test code in place, create a project template and an item template, called "TDDUnitTestPlroject" and "TDDUnitTest" respectively. From now on, you can use these templates for TDD unit test projects and you don't need to write the same code again and again.
Yes. One way to do this is to make the methods being tested throw NotImplementedException. As you build out your code, your tests will eventually pass (once you've identified and fixed detected bugs). Of course, you also need to perform system (vs. unit) testing to help ensure product quality.
The approach you seem to be describing here is not TDD though. You don't start with a coded class, you start with the tests and build your functionality out of this. What am I missing in your solution that makes it suitable for TDD?
I don't really understand this question. If you're using fundamentalist TDD, you should write the tests first, before you have any code, and so there is nothing for automated code generation to work with. (A full scale TDDer would write tests that don't even compile before writing the methods that it references.) And if you're not, don't worry about this rule, just write the content of the test so that it actually ... well, tests stuff.
If you're using fundamentalist TDD, you should write the tests first
Yes, that is exactly how we started. For TDD, you create a test project using VS 2008 (or NUnit, etc). You notice that your test project actually compiles and runs successfully, even without implementing your souce project.
In terms of TDD, the common problem with most test frameworks is that before you write the source project, your test project won't fail. Of course, this is kind of formal TDD requirement that many people don't care.
I think you have misunderstood something about TDD here. As Pete says, TDD doesn't specify that the project should fail, it specifies that individual tests should fail when you first write them. An empty project contains no tests, and so (obviously) nothing fails, but that's because you haven't written any tests and therefore (in pure TDD) your program has no requirements.
I think I understand TDD correctly. The test project is a wrapper of one or more tests. When I said that the test project fails, I meant that one or more tests (or test methods) fail.
This is the TDD workflow I use:
1) Add a test
2) Run the test
2.1) if the run succeeds, go to step 1).
2.2) if the run fails, write some source code; go to step 2).
Note that the source code is the unit under test, not the test itself. Don't confuse TDD with normal unit test. In TDD, we create the unit test before creating the unit. The unit test should not pass before we have the unit.
Last Visit: 31-Dec-99 19:00 Last Update: 29-Jan-23 5:08