<div dir="ltr">Thanks, Sean.<br><br><div class="gmail_quote">On Tue, Sep 9, 2008 at 3:46 PM, Sean Leather <span dir="ltr">&lt;<a href="mailto:leather@cs.uu.nl">leather@cs.uu.nl</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div class="Ih2E3d"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div dir="ltr">How do folks like to package up QuickCheck tests for their libraries?&nbsp; In the main library?&nbsp; As a separate repo &amp; package?&nbsp; Same repo &amp; separate package?&nbsp; Keeping tests with the tested code allows testing of non-exported functionality, but can add quite a lot of clutter.<br>



</div></blockquote></div></div><div><br>I have QuickCheck properties plus HUnit tests, but I think the question is the same. For me, it&#39;s in the same repository and shipped with the package source. I think that if you ship source (even via Hackage), you should also ship tests. So, if somebody wants to modify the source, they can run the tests. And making it convenient to test is very important, so I have &quot;cabal test&quot; (or &quot;runhaskell Setup.hs test&quot; without cabal-install) configured to run the tests. I don&#39;t think tests should (in general) be part of the user-visible API, so I have them external to the module hierarchy.</div>
</div></div></div></div></blockquote><div class="Ih2E3d">&nbsp;<br>How do you set up cabal to do these tests?<br><br>Do your libraries depend on HUnit?<br><br></div><div class="Ih2E3d">Where do you like to place your tests?&nbsp; In the functionality modules?&nbsp; A parallel structure?&nbsp; A single Test.hs file somewhere?<br>
</div><div class="Ih2E3d"><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Testing non-exported functionality without exporting the test interface seems difficult in general. Is there a way to hide part of a module interface with Cabal? Then, you could have a &#39;test&#39; function exported from each module for testing but hidden for release.<br>
</blockquote>



<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div>
</div><div class="Ih2E3d"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">My current leaning is to split a package &quot;foo&quot; into packages &quot;foo&quot; and &quot;foo-test&quot;<br>


</div></blockquote><div>&nbsp;</div></div></div></div><div class="Ih2E3d">What benefit does this provide?</div></div></div></div></blockquote><div><br>It keeps the library and its dependencies small.&nbsp; Probably some of the alternatives do as well.&nbsp; For testing, I&#39;m using <a href="http://haskell.org/haskellwiki/Checkers">checkers</a> in addition to QuickCheck, and I&#39;d prefer not to make casual library users have to pull in those libraries as well.<br>
<br>&nbsp; - Conal<br></div></div><br></div>