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.<div>
<br></div><div>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).</div>
<div><br></div><div>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 packages to deal with, and so that the source for the unit tests is included when you get the package from hackage. </div>
<div><br></div><div>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:</div>
<div><br></div><div> 1. always export the unit tests</div><div> 2. create a separate cabal package for each happstack package which just contains the unit tests.</div><div><br></div><div>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.</div>
<div><br></div><div>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 :(</div>
<div><br></div><div>- jeremy</div><div><div><div><br><div class="gmail_quote">On Sun, Mar 28, 2010 at 6:35 PM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com">ivan.miljenovic@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Jeremy Shaw <<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>> writes:<br>
> I keep running into issues where I want to use some version of parsec,<br>
> quickcheck, haxml, etc, in my code, but my code links against a different<br>
> third party library (e.g. network) which uses a different version of the<br>
> library (e.g., parsec) than what I want to use, and that makes cabal<br>
> unhappy.<br>
<br>
</div>Better (well, OK, maybe not _better_ per se but relevant) question: why<br>
isn't QuickCheck usage optional in so many of these libraries? There<br>
should be no reason for most people to build the testing functions,<br>
etc. in these libraries.<br>
<font color="#888888"><br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" target="_blank">IvanMiljenovic.wordpress.com</a><br>
</font></blockquote></div><br></div></div></div>