<div dir="ltr"><br><div class="gmail_quote"><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 class="Ih2E3d">
<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><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><div>&nbsp;<br>How do you set up cabal to do these tests?<br></div></div></div></blockquote><div><br>I use the &quot;runTests&quot; hook in Distribution.Simple. The code below works on Windows and Mac, because that&#39;s what we use.<br>
<br>\begin{code}<br>module Main (main) where<br><br>import Distribution.Simple<br>import System.Cmd (system)<br>import System.FilePath ((&lt;/&gt;))<br><br>main :: IO ()<br>main = defaultMainWithHooks hooks where<br>&nbsp; hooks = simpleUserHooks { runTests = runTests&#39; }<br>
<br>runTests&#39; _ _ _ _ = system cmd &gt;&gt; return ()<br>&nbsp; where testdir = &quot;dist&quot; &lt;/&gt; &quot;build&quot; &lt;/&gt; &quot;test&quot;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; testcmd = &quot;.&quot; &lt;/&gt; &quot;test&quot;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cmd = &quot;cd &quot; ++ testdir ++ &quot; &amp;&amp; &quot; ++ testcmd<br>
\end{code}<br><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>Do your libraries depend on HUnit?<br>
</div></div></div></blockquote><div><br>No, because I use an ultra-secret trick. ;) I have a Library in my .cabal file and an Executable for testing. Part of the test description follows.<br><br>\begin{cabal}<br>Executable test<br>
&nbsp; hs-source-dirs:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; src, tests, examples<br>&nbsp; main-is:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Main.hs<br><br>&nbsp; -- Only enable the build-depends here if configured with &quot;-ftest&quot;. This<br>&nbsp; -- keeps users from having to install QuickCheck 2 in order to use EMGM.<br>
&nbsp; if flag(test)<br>&nbsp;&nbsp;&nbsp; build-depends:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; QuickCheck &gt;= 2.0, HUnit &gt;= 1.2<br>&nbsp; else<br>&nbsp;&nbsp;&nbsp; buildable:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; False<br>\end{cabal}<br><br>With that last flag-based if/else, I hide the dependencies for normal building (&#39;test&#39; by default is False). If &#39;test&#39; is False, then the executable also cannot be built.<br>
<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>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"><div></div></div></div></div></blockquote><div><br>In a separate &quot;tests&quot; directory at the same level as the &quot;src&quot; directory containing the module hierarchy. It has a number of files, mostly one per module tested.<br>
<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 class="Ih2E3d"><div><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><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>What benefit does this provide?</div></div></div></div></blockquote></div><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" target="_blank">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>

</div></div></div></blockquote><div><br>Ah, so you&#39;re handling the same problem we are in a different way. Nice!<br><br>Sean<br></div></div></div>