|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |