<div dir="ltr"><br><div class="gmail_quote"><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">How do folks like to package up QuickCheck tests for their libraries? In the main library? As a separate repo & package? Same repo & separate package? 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><br>I have QuickCheck properties plus HUnit tests, but I think the question is the same. For me, it'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 "cabal test" (or "runhaskell Setup.hs test" without cabal-install) configured to run the tests. I don't think tests should (in general) be part of the user-visible API, so I have them external to the module hierarchy.<br>
<br>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 'test' function exported from each module for testing but hidden for release.<br>
<br></div><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">My current leaning is to split a package "foo" into packages "foo" and "foo-test"<br>
</div></blockquote><div> </div></div></div>What benefit does this provide?<br><br>Thanks,<br>Sean<br></div>
</div></div>