Darren New wrote:

> Yep. Every time you use "assert" to check your inputs, you're doing 
> that. Except with minimal language assistance.

Eiffel has preconditions *and* postconditions, which most people don't 
seem to bother checking with assert() calls.

> Unit testing just takes those asserts outside the function.

Whilst Haskell does have an assert() function, it seems to be more 
popular to use QuickCheck.

QuickCheck does automated randomised testing. Give QC a property that's 
supposed to hold for any inputs, and it generates inputs at random and 
checks whether the property holds.

The big snag, of course, if that if your code fails only under very 
specific, rare circumstances, randomised testing might not hit the bug. 
(This is why books on testing talk about testing limits, flow control 
paths, etc.)

Also, asserts or design by contract will catch the source of a crash in 
a live running program. (Assuming that enabling the tests doesn't slow 
the program to the speed of a glacier...)

>> On top of that, any kind of testing is going to be easier if a 
>> function's output depends only on its current inputs...
> 
> Yep. The problem with "unit testing" per se is that it only tests a 
> unit. It doesn't test anything except the invariants of the unit you're 
> testing.

I thought the idea was that you then combine several units into a larger 
unit, and test that (and so on, recursively). Then again, maybe that's 
what they mean by "integration testing"...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message