Go kind of makes you do this. Last weekend I was writing some code, ran the tests, and saw that they failed. I debugged my test harness for a while, only to find that the bug was actually in my real code. (Overall I kind of like the strategy, I'd much rather debug my own for-loop-over-test-data than someone else's. But it does lead the mind down different paths than when you use something like JUnit/Hamcrest.)
Incidentally, this is why "test first" is more than just a methodology for selling high-priced consultants. At least it lets you see your tests fail and then pass, rather than just pass. Lots of common patterns pass in the presence of incorrect code.
An example that a coworker was complaining to me about recently:
void testFooBarException() {
try {
thisShouldThrowFooBarException()
} catch (FooBarException ignored) {}
}
Can you spot the bug? The test still passes even if thisShouldThrowFooBarException doesn't throw an exception. Oops.
I personally avoid this by checking that I can make the test fail when I expect it to fail, by editing some values or commenting something out. But that doesn't scale, that only saves you once.
Something to think about.
Incidentally, this is why "test first" is more than just a methodology for selling high-priced consultants. At least it lets you see your tests fail and then pass, rather than just pass. Lots of common patterns pass in the presence of incorrect code.
An example that a coworker was complaining to me about recently:
Can you spot the bug? The test still passes even if thisShouldThrowFooBarException doesn't throw an exception. Oops.I personally avoid this by checking that I can make the test fail when I expect it to fail, by editing some values or commenting something out. But that doesn't scale, that only saves you once.
Something to think about.