[Haskell-cafe] HUnit/cabal integration

[Simon Hengel]

> First: the web page I cite above describes the interface that the test
> binary must support to work with cabal, specifically w.r.t. the binary's
> exit code.  "Your test suites likely already fit this model.  However, if
> you are using an old version of QuickCheck or HUnit, your executable may
> not be returning the correct error code."
> 
> This seems to me to suggest that recent versions of HUnit automatically
> take care of generating the exit code, but I've found that I have to
> examine HUnit's results and synthesize the exit code manually, as in the
> driver program below.  (I'm running HUnit 1.2.4.2, but the interface for
> 1.2.4.3 doesn't appear to differ on this point.)  Am I misinterpreting the
> wiki page, or am I missing something in HUnit's API that generates the exit
> code automatically?

AFAIK, you have to do it explicitly.  But you can shorten it to
something like this:

    when (errors c /= 0 || failures c /= 0)
      exitFailure

Personally I'd use some test framework that is build on top of HUnit and
QuickCheck.  My weapon of choice is Hspec [1], but there are other
options.

> Second: Am I specifying the Build-Depends correctly for the Test-Suite?
> Specifically: do I need to state a dependency on the library defined in the
> same package, or does it pick that up automatically?  Further, foo-tests
> doesn't use parsec directly.  Is the transitive dependency automatically
> provided for me, or do I need to list it explicitly as below?

You only have to add dependencies on what you actually use, so if you
depend on your library and only use stuff from your library, you do not
need to depend on parsec.

On a broader scope, you have two options, either

(a) Depend on your library in your Cabal test section.

or

(b) Include the source files of your library in your Cabal test section.

Whether you want (a) or (b) depends on the circumstances.  Here is a
(possibly not complete) list of differences:


 - (a) Is suitable when you only want to test the public interface of
   your library, but it does not allow you to test stuff that is not
   exposed.  In contrast, (b) allows you to test stuff that is not
   exposed.

 - (a) usually gives you a short test section in your Cabal file (and is
   more DRY). (b) requires you to repeat all dependencies, options, etc.
   of your library section in your test section.

 - Compilation is slower with (b), because the source files of your
   library are compiled twice.

 - (b) even works in the rare case, when your test framework depends on
   your library (e.g. if you use HUnit to test a dependency of HUnit).

I'm assuming here, that your library sources and test sources live in
different directory hierarchies, and I'm not sure what the exact
behavior is, if they don't!

Let's look at an example.  If your library sources are in '.' and your
test sources are in 'test' option (a) looks like so:

  test-suite foo-tests
    type:
        exitcode-stdio-1.0
    main-is:
        foo-tests.hs
    hs-source-dirs:
        test
    build-depends:
        base >= 4.3.1.0 && < 5
      , foo                    -- depend on your library
      , HUnit >= 1.2.4.2

And option (b) looks like so:

  test-suite foo-tests
    type:
        exitcode-stdio-1.0
    main-is:
        foo-tests.hs
    hs-source-dirs:
        .                      -- include the sources of your library
      , test
    build-depends:
        base >= 4.3.1.0 && < 5
      , parsec >= 3.1.2        -- inculde the depencencies of your library
      , HUnit >= 1.2.4.2

Hope that helps.  Feel free to ask, if anything is unclear.

Cheers,
Simon

[1] http://hspec.github.com/