Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How should I go about testing a monolithic executable package?

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?

like image 895
Ignat Insarov Avatar asked Dec 13 '22 15:12

Ignat Insarov


1 Answers

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.

like image 94
Shersh Avatar answered Mar 16 '23 13:03

Shersh