I just started a new project, and now with ASP.NET MVC being designed in an extremely composable way, I figured it might be a good time to start with unit testing. Most of my code is fresh, and I'm writing the tests before I'm writing the actual production code.
My frustration, though, is that I spend a lot more time fixing mistakes in my tests than in fixing anything wrong with my production tests.
My typical workflow ends up being something like this:
- Write a stub
- Write the test
- Ensure that the test fails
- Fill in the stub
- The test still fails, so spend a while going over the expected and actual output.
- The error turns out to be in the test, not the actual code. Fix the test.
If you think about it, this is somewhat to be expected: unit tests involve producing output by hand and so is error-prone; code written in a strict language and with good coding practices has behavior that is specified very much automatically.
Of course, there are odd times when my production code is the actual cause of a test failing, but it's just really comparatively rare.
There's no reason to eliminate unit tests entirely, of course; there are times when I simply don't trust my own code at all. On the other hand, I'm starting to feel like it's not all that valuable -- especially the test-first philosophy.
Anyone else feel this way?