ajb@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"++)