[EMAIL PROTECTED] 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"++) _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe