Question

我有一个带有多个模块的整体式executable封装。 （我的意思是“整体式”是指它的cabal文件中只有一个子句，即executable。）目前，它已在shell脚本中进行了测试，黑匣子的方式。我以为我想为某些单独的功能编写单元测试，但是cabal不同意：

% 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

以下是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

我的理解是，我应该将尽可能多的模块移至内部库，这将使测试套件能够依赖它们。但是，我不确定维护者是否会赞成这种根本性的改变。有没有一种侵入性较小的方法？

我的另一个担心是，在Main.hs子句中executable x中，我们不能将其中的功能（至少{{1} }）将无法进行测试。那么，除了外壳程序脚本之外，我应该如何测试这些功能？

Answer 1

将模块移至library节（如果您不想公开这些模块，则为内部库节）是完全可以的。

除了外壳程序脚本外，我应该如何进行测试？

在Haskell世界中，有一种惯例将所有内容（甚至是main函数）移到library中，因此您的Main.hs看起来像这样：

module Main where

import MyLib as Lib (main)

main :: IO ()
main = Lib.main

通过这种方法，您可以通过Haskell单元测试库完全测试所有内容。

但是，我不确定维护者是否会赞成这种根本性的改变。有没有一种侵入性较小的方法？

好吧，如果维护者关心他们的软件包，那么他们想要更好的测试就应该同意这种重构。

Answer 2

如果不是将软件包移动到（也许是内部）库的选项，则只需将可执行文件的所有源添加到测试套件的hs-source-dirs中，然后将可执行文件的依赖项添加到测试套件的build-depends。

这样做的缺点是您将两次编译相同的文件：一次用于可执行文件，一次用于测试套件。

我应该如何测试整体可执行包？

2 个答案: