At 21:07 01/01/04 -0500, ajb@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