How should I go about testing a monolithic executable package?

Question

I have a monolithic executable package with several modules. (What I mean by "monolithic" is that it only has one clause in its cabal file, and that is executable.) It is currently tested with shell scripts, in a black box manner. I thought I would like to write unit tests for some individual functions, but cabal does not agree:

% cabal new-test
cabal: Cannot test the package x-0.0.0.0 because none of the
components are available to build: the test suite 'x-test' is not
available because the solver did not find a plan that included the test suites

Here are the relevant sections of package.cabal:

executable x
  ...
  other-modules: ...
  ...

test-suite x-test
    type: exitcode-stdio-1.0
    main-is: Test.hs
    build-depends: base, x
    hs-source-dirs: test

My understanding is that I should move as many modules as possible to an internal library, which would make it possible for the test suite to depend on them. However, I am not sure the maintainers will approve of such radical change. Is there a less invasive way?

My other concern is that, insofar as Main.hs is in the executable x clause, and we cannot import that into x-test, the functions therein (at the very least main) will be unavailable for testing. How should I go about testing these functions then, beside shell scripts?

Answer 1

It's completely okay to move modules to library stanza (or internal library stanza if you don't want to expose those modules).

How should I go about testing it, beside shell scripts?

There's a common practice in Haskell world to move everything (even main function) into library so your Main.hs would look like this:

module Main where

import MyLib as Lib (main)

main :: IO ()
main = Lib.main

With this approach you can test completely everything via Haskell unit testing libraries.

However, I am not sure the maintainers will approve of such radical change. Is there a less invasive way?

Well, if maintainers care about their package, they should agree to this refactoring if they want better testing.

Answer 2

If moving the packages to a (perhaps internal) library is not an option, you could simply add all the sources of the executable to the hs-source-dirs of the test suite, and also add the dependencies of the executable to the build-depends of the test suite.

This has the disadvantage that you'll compile the same files twice: once for the executable and once for the test suite.