Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Let us not forget, of course, that in a "normal" language it's not in 
>> any way unusual for changing the structure of a program to cause some 
>> new, previously unused code path to suddenly get used and reveal a bug 
>> or two that you didn't know about.
> 
>   It's just that with lazy evaluation even if you *do* execute all possible
> code paths that doesn't guarantee that their result is actually calculated.
> Thus code coverage might not have the same degree of guarantee than with
> other languages.

Depends on what you do with the results.

If you do "nothing" with them then no, they won't be computed. If you, 
say, check that the generated result matches an expected result, then 
the way equality is *usually* implemented will ensure that the full 
result is indeed computed.

If your program is *supposed* to generate an infinite result set then 
yeah, you have a problem. You'll have to check that some finite portion 
of it matches what it's supposed to be. ;-)

One of the nice properties of Haskell is that since a function can have 
no side effects, you "only" need to check that it produces the correct 
output for every valid input. (Yeah, I realise that's usually still 
impossible - but it beats having to ensure that global variables get 
initialised first and aren't corrupted afterwards, checking for thread 
safety, etc.)

GHC actually comes with a library called Quick Check, who's purpose is 
to automatically generate (randomised) test cases and check arbitrary 
properties that you specify. (Obviously they must be *computable* 
properties - in fact _you_ have to specify the algorithm for checking 
the result is acceptable.) The only snag is that you need to be careful 
with how you randomise so you get a "meaningful" sample.

There are people in the Haskell community who are very obsessive about 
always writing Quick Check properties for all code developed. 
Personally, I sometimes find that devising meaningful tests that are 
machine-checkable can be as hard as writing the code I want to check... ;-)

The times I have used Quick Check, it's been quite helpful. For example, 
a while back a started work on a small library to do binary 
serialisation. (As in, read and write integers of arbitrary width, not 
limited to being byte-aligned.) QC has invaluable in quickly generating 
lots of random inputs, writing then and reading them back, and checking 
the result match. Usually if there was a bug, it found it in split 
seconds. Much quicker than typing in tests by hand...

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

Post a reply to this message