Fog Creek Software
Discussion Board




"Writing test cases takes too long"

I'm reading up on refactoring at the moment and I re-read Joel's "Things you should never do - Part 1" ( http://www.joelonsoftware.com/articles/fog0000000069.html ). I got to thinking about a cry I hear regularly from developers - "Writing test cases takes too long". It appears that writing a thorough set of test cases takes approximately twice as long as writing the code.

Does this sound right ? It kinda makes sense to me, since time is required to set up configurations, write the test cases and fix any errors in either the test cases or the code.

What's your experience been?

Astarte
Wednesday, August 06, 2003

i think that for this kind of stuff, the time-gain is noticable afterwards when test-cases could prevent breaking of the code.

Guyon Morée
Wednesday, August 06, 2003

Yeah, doesn't manual testing and debugging take at least twice as long as writing the original code?

Andy
Wednesday, August 06, 2003

I've been trying to move to test driven development and have written a few pieces on it over on my blog: http://www.lenholgate.com/

In general I've found that writing tests and code does seem to take about twice to three times as long as just writing code. The difference is that this time is the length of time from starting writing code to the time the code works. When comparing with writing code without tests you are comparing with the time from starting writing the code to when you think you're done.

I've found that it actually works out quite a bit quicker to write tests. Not only do you think about the code you're writing a little more but you can skip that whole random debugging phase.

The time the tests really pay for themselves though is when you need to change things. The code that has tests stays working and can be tested automatically and often. The code without tests might still work or might get broken in a subtle way that takes ages (or a real user) to find.

I'm not hooked yet. But then at present I'm mostly working on code without existing tests; I have to make a judgement call each time I need to work on code that is currently untestable. To refactor, make testable and write a few tests takes a lot longer than just spelunking around in the code and hacking in a fix; I almost always regret chosing not to write the tests.

I've also found that writing the tests first makes the whole development process less stressful. There's none of this 'does this change break that thing' worrying. The tests tell you.

Len Holgate
Wednesday, August 06, 2003

I've found that writing test cases first increases overall productivity, even though it seems counterintuitive. Two factors play into it.

The first, as others have mentioned, is that usually by the time you're done writing the code in TDD, the code has orders of magnitude less bugs in it than when you write the code without tests.

The second is that TDD offers a sense of scope. If you limits your tests to just the required functionality, and stop coding when the tests are passed, you'll often end up having written less code. It's a way to help keep feature-creep in check.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, August 06, 2003

We're gradually moving over to test first development at work. Our build process automatically runs all of the test cases we "register" during the nightly build. It does take some time to write a test case, and it sometimes seems like a waste for a simple change, however, we've found it really pays off for the reasons people have already stated. You know that the change actually produces the wanted results, and that it's going to continue to do so in the future even as other people change other parts of the code. We've already caught several "errors" in this way. It may look like it takes longer but as was mentioned that's only becuase you comparing the time it takes to write some code you think works to the time it takes to write some code you know works.

Alex Moffat
Wednesday, August 06, 2003

If you don't write a lot of bugs then development
plus good system tests will work.

If you like testing as part of the design process
then it's not extra work, it's just part of coding,
with the added benifit you know it mostly
works.

valraven
Wednesday, August 06, 2003

*  Recent Topics

*  Fog Creek Home