Re: Test/ Code Ratio

[tstock]

I think the amount of testing needed on a given app is particular to each app and business needs. I think I test more than most around me, but I don't come close to having 1/3 of my code as test code. If you include inline testing, validation, defensive coding, as test code, then I may come close to that, otherwise, my test code is probably in the 1/5 to 1/10 range.

I think that if the action of writting a test and running that test everytime you run a test harness causes more pain than the advantage of having that test, then you probably went overboard. I understand it's hard to measure something that hasn't happended yet (and may never happen), this is just a rought low bar for writting a test.

Something else that a recent Joel on Software article touched on, "if the cost of fixing a bug is more expensive than what leaving the bug in is likely to cost in the long run, then maybe the bug doesn't need to be fixed". horrors. In those cases, maybe writting tests for those possible bugs is also going overboard ?

OK, burn me at the stake now...

Tiago

[thor]

maybe writting tests for those possible bugs is also going overboard ?

There are two situations that your statement made me think of. In both, I'll argue in favor of writing the test.

The first case is some edge case that "will always be true...duh!". Dollars to donuts, something will change to break your assumption. At that point, you'll be glad that you had the test in place.

The second situation is a known bug that your customer has told you is acceptable. In this case, write the test, but set it to be ignored in your suite. That way, when some big wig walks up and says "did we know about this? the client is fumming!", you can say "yep, and here's the test case that Mary Jones told us to ignore on 17Nov2004".

[DrHyde]

Most of my tests aren't there to find bugs in the current version. They're regression tests to stop me introducing bugs next week.