id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
2608,Direct support for unit tests in Cabal,kaol,,"I'm passing along Debian wishlist bug [http://bugs.debian.org/458495 #458495] for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having.

I didn't look overly much if something like this has been already implemented. My apologies if this is just more noise.

----
It would be nice if there was a simple way to build and run tests for
Cabalized packages.

Cabal provides a ""test"" target, but by default it does nothing.
Furthermore, you can't really build test cases using the Cabal
infrastructure, since any executables that you list get installed.
Searching on Google for how to integrate a test suite into Cabal turns
up suggestions such as ""make a system() call from runTests to 

The attached patch adds two new flags to the build information for
executables and libraries:

{{{
  * do-not-install: if set to True, keeps an executable that it's set on
    from being installed.  This is necessary to keep test suites from
    ending up in $prefix/bin, but may be useful for other build-time
    utilities.

  * is-test: if set to True on an executable, the executable will be
    invoked by the ""test"" target of the setup script.  Note that this
    doesn't attempt to be at all smart about building the executable(s);
    it just blindly invokes the test command(s) and returns a failure if
    any of them fail.
}}}

The patch should be fairly straightforward.  The need to do suppression
of installing executables in compiler-specific code is a bit ugly;
this could maybe be cleaned up with an equivalent to withExe that drops
non-installed executables and by writing and using a similar routine for
libraries.

This also changes the API of Cabal: runTests now takes an integer as
its first argument, indicating the verbosity level provided as an
argument on the command-line.  The Boolean that was passed before
didn't have any purpose I could see and was always False, so it
shouldn't be hard to adapt existing code to this change.  On the other
hand, the API can be preserved by just hard-coding a verbosity level.
",proposal,closed,normal,6.12 branch,libraries (other),6.6.1,invalid,,,Unknown/Multiple,Unknown/Multiple,,Unknown,,,,