How to make auto-generated unit tests fail initially?
-
Would you care to elaborate. You have got me interested in this TDDUnitTest idea.
"You get that on the big jobs."
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.
Best, Jun
-
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. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
One way to do this is to make the methods being tested throw
NotImplementedException.Yes, that would work for each of the unfinished methods after the class is coded.
Ravi Bhavnani wrote:
Of course, you also need to perform system (vs. unit) testing to help ensure product quality.
Absolutely. Usually, unit test is tedious and costly. By using some sort of test framework, we could simplify and automate the process significantly.
Best, Jun
-
Ravi Bhavnani wrote:
One way to do this is to make the methods being tested throw
NotImplementedException.Yes, that would work for each of the unfinished methods after the class is coded.
Ravi Bhavnani wrote:
Of course, you also need to perform system (vs. unit) testing to help ensure product quality.
Absolutely. Usually, unit test is tedious and costly. By using some sort of test framework, we could simplify and automate the process significantly.
Best, Jun
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?
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
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?
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
I start with classes that contain unimplemented methods, causing their tests to intially all fail. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I start with classes that contain unimplemented methods, causing their tests to intially all fail. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
If you strictly follow TDD, then your first tests don't actually have any corresponding methods.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
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?
Best, Jun
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.
-
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.
BobJanova wrote:
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.
Best, Jun
-
BobJanova wrote:
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.
Best, Jun
Jun Du wrote:
You notice that your test project actually compiles and runs successfully, even without implementing your souce project.
And that's exactly the way it should be. TDD doesn't say that your test project should fail, it says that the actual application code starts off by failing and you add tests and code in harmony.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
BobJanova wrote:
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.
Best, Jun
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 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). 3)Done 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.
Best, Jun
-
If you strictly follow TDD, then your first tests don't actually have any corresponding methods.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
You could add the test method before you implement a method. You did the same with classes. I think this is what "write test first, then write code" really means. You also could create method signatures (input/ouput parameters and return type) without method body. After having the method signatures, you can write the test method to test the method.
Best, Jun
-
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). 3)Done 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.
Best, Jun
Yes, that's correct, but until you write a test it makes no sense to worry about whether the test project compiles and runs. Actually one could argue that it should succeed because with no tests, your program has no requirements and so it will pass them all (it's easy to do nothing).