
From a source code management viewpoint, it is nice to have the unit tests in the package (such as happstack-data) so that we don't have twice as many
In the case of happstack, the happstack-util library provided a function that converted QuickCheck unit tests into HUnit unit tests. happstack-util exported this so that the other happstack-* packages could use it as well. We did not actually have the unit tests themselves enabled by default. Though that is actually a problem as well. The theory (at the time) was that every happstack-* package would export its unit tests. The top-level happstack package could then import all the unit tests into a bigger testsuite and run them all. (And the bigger testsuite would be re-exported so that you could include the happstack testsuite in your applications own test suite). packages to deal with, and so that the source for the unit tests is included when you get the package from hackage. We should not simply make the unit tests be a compile time flag in the .cabal, because there is no way for the happstack parent package to depend on the version of happstack-data (for example) which has the unit tests enable. So, the only solutions are: 1. always export the unit tests 2. create a separate cabal package for each happstack package which just contains the unit tests. The first option is much easier -- except that it requires QC, which is especially problematic at the moment. So ultimately, we will have to move to the second option I guess. As a work around, we did just make all the QC related stuff enabled via a flag. But it does cause problems when trying to build the test suite in the buildbot because happstack-data gets rebuilt with out the tests enabled :( - jeremy On Sun, Mar 28, 2010 at 6:35 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
Jeremy Shaw
writes: I keep running into issues where I want to use some version of parsec, quickcheck, haxml, etc, in my code, but my code links against a different third party library (e.g. network) which uses a different version of the library (e.g., parsec) than what I want to use, and that makes cabal unhappy.
Better (well, OK, maybe not _better_ per se but relevant) question: why isn't QuickCheck usage optional in so many of these libraries? There should be no reason for most people to build the testing functions, etc. in these libraries.
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com