[prog] Unit testing

[drichter at essi.fr]

Hi everyone.

I've discovered the power of unit testing. I use it even in my personal 
projects, and it's all the more important when several people are hacking the 
same code base.

But I have a question: how well should you document your unit tests? Mine often 
have code that's difficult to follow because they're just slapped together. 
This makes for fast coding, which is important for two reasons. First, you want 
a lot of unit tests. Second, your unit tests may be obsolete with the next 
revision of the program, so you shouldn't spend too much time on them.

But when a test fails, you usually want to retrace the steps to see where it's 
failing, so that you know how to reproduce the bug. With some tests it's 
trivial because the test is simple. For example, if you have your own square 
root function and it fails a test, all you have to say is: "sqrt(4) returned 87 
when it should return 2," and that's enough to reproduce the bug. But unit 
tests often involve components that maintain state information, so to reproduce 
the bug you have to follow a multi-step test routine exactly. And that calls 
for easy-to-read code.

So what do you think? Should unit tests be coded quickly or well?

-- 
   As Defendant [Microsoft] is well aware, its proposal has been
   criticized for "exceptions which swallow the rule."
       - Judge Colleen Kollar-Kotelly, chastizing Microsoft
         in the state antitrust lawsuit.



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/