Perspectives on learning and using Haskell
GK at ninebynine.org
Sun Jan 4 10:20:39 EST 2004
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?
More information about the Haskell-Cafe