Perspectives on learning and using Haskell

[Graham Klyne]

At 21:07 01/01/04 -0500, ajb at spamcop.net wrote:
>In Haskell, I find myself
>occasionally having to expose parts of a module which I would prefer not
>to, in order for the unit tests suite to do their job effectively.

Yes, I've found that too.

But I also wonder if this is a sign that the XP approach to test-led 
development isn't being followed faithfully.  Theoretically (as I 
understand XP), the tests *are* the specification.  And things that aren't 
exposed can't be part of the specification, can they?

In practice, I think that there's a slight tension here:  tests may embody 
the specification, but they also embody some knowledge of the way the code 
works, and (I occasionally find) some may be created to provide a finer 
granularity of information about how the code is *mis*functioning.  I'm 
finding my development strategy is evolving to make more use of separate 
"spike" modules to test code fragments, so there's less need for this kind 
of white box influence in the test code.

Which leads to a question:  I've been thinking that the "white box" tests 
may be better served by test expressions coded *within* the module 
concerned.  In many cases, I create these, then en-comment them when the 
code is working.  I would expect that when using GHC to compile a 
stand-alone Haskell program, any expressions that are not referenced are 
not included in the final object program, so leaving these test cases 
uncommented would be harmless:  is this so?

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact