Perspectives on learning and using Haskell

[Shae Matijs Erisson]

ajb at spamcop.net writes:

> There is only one problem I've found with test-driven development in
> Haskell.  In C++, it's possible to break the "module" abstraction
> (yes, I know, C++ doesn't have modules; it has classes, which are really
> instantiable modules) by using "friend".  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.

My one problem with test-driven Haskell is, how to do it with QuickCheck tests?
It's easy enough with HUnit, but I'd like to try it with QuickCheck, any
suggestions?

> I wonder if there might be a way to fix this, say, by allowing modules
> to selectively expose parts of their interface depending on who wants
> to use it.

What about GHC's new -main-is flag to specify a test main function? Then you
may be able to write test code without exporting internal functions.


As for tighter integration of tests with code, I wrote an example of one-button
unit-testing in emacs on the HaskellMode page on the HaWiki, and the
Programatica editor, as demonstrated at Haskell Workshop 2003 has the ability
to embed 'certificates' that can be proofs, unit tests, etc.
Check out the Evidence Management section here:
http://www.cse.ogi.edu/~hallgren/Programatica/HW2003/demoabstract.html 

There's also the darcs_test parts of darcs, you can assign a script to run
tests after a variety of darcs commands. 

None of these run the tests at compile time, but it's better than manually
running the tests.
-- 
Shae Matijs Erisson - 2 days older than RFC0226
#haskell on irc.freenode.net - We Put the Funk in Funktion
10 PRINT "HELLO" 20 GOTO 10 ; putStr $ fix ("HELLO\n"++)