组织Haskell测试

所以我试图按照suggested structure of a Haskell project，我组织我的测试有几个问题。组织Haskell测试

为了简单起见，让我们开始：

src/Clue/Cards.hs # defines Clue.Cards module 
testsuite/tests/Clue/Cards.hs # tests Clue.Cards module

原因之一，我不知道什么名字的testsuite/tests/Clue/Cards.hs包含测试代码的模块，和另一个，我不知道如何编译我的测试代码，这样我可以链接到我的源：

% ghc -c testsuite/tests/Clue/Cards.hs -L src 
testsuite/tests/Clue/Cards.hs:5:0: 
    Failed to load interface for `Clue.Cards': 
     Use -v to see a list of the files searched for.

来源

2011-01-14 rampion

我用我自己的Snap Framework他们的测试套件，它基本上可以归结为采取的办法：

使用一个测试框架，如haskell-test-framework或HTF

名称含有测试模块附加.Tests含有IUT，例如，模块名：

module Clue.Cards where ... -- module containing IUT 

module Clue.Cards.Tests where ... -- module containing tests for IUT

通过使用单独的名称空间，您可以将测试放在单独的源文件夹tests/中，然后您可以使用单独的Cabal生成目标（另请参阅cabal test最近Cabal版本的生成目标支持），该测试套件包括其中的其他源文件夹hs-source-dirs设置，如：
```
Executable clue 
    hs-source-dirs: src 
    ... 

Executable clue-testsuite 
    hs-source-dirs: src tests 
    ... 
```
这工作，因为在你的IUT的模块和测试套件之间没有命名空间冲突了。

来源

2011-01-14 07:40:49 hvr

+1提到快照框架，在这方面组织得非常好。 – 2011-01-14 12:33:05

很酷。我使用这个项目作为学习Haskell生态系统的一种方式（我认为任何人都不愿意执行Clue/Cluedo的规则），而且我还没有解决cabal问题，所以这是一个很好的开始。裤子。我会弄清楚如何使用cabal，然后绕回到测试。 – rampion 2011-01-14 13:05:52

我个人觉得，一个额外的./src/目录没有多大意义的小哈斯克尔项目。粗略的来源，我下载了源代码。

无论哪种方式（有或无SRC），我建议你重构，并有Clue目录和Test目录：

./Clue/Cards.hs -- module Clude.Cards where ... 
./Test/Cards.hs -- module Test.Cards where ...

这使得GHCI + Test.Cards看到没有任何Clue.Cards额外的参数或使用cabal。在该说明中，如果您不使用cabal +标志来选择构建测试模块，那么您应该查看它。

另一种选择，这是我在我的很多项目都使用，是有：

./Some/Module/Hierarchy/File.hs 
./tests/someTests.hs

我cabal install包然后运行tests/someTests.hs东西。如果我的软件包特别大，而且安装时间太长，我想这会很麻烦。

来源

2011-01-14 05:00:53

我认为一个额外的`src`目录总是有意义的，因为它限定了源代码层次结构中实际包含的内容：Haskell sources！当你的应用程序中有其他东西时，这是非常有用的，比如脚本，配置文件和其他非Haskell源代码。 – fatuhoku 2013-03-12 14:48:35

这里的另一种方式：

每个模块的单元测试定义为hunit TestList at the end of the module，与一些一致的命名方案，如“tests_Path_To_Module”。我认为这有助于我编写测试，因为我不必在源代码树中搜索远处的另一个模块，也不需要保持两个并行文件层次结构同步。

模块的测试列表还包含任何子模块的测试。Hunit的runTestTT转轮内置于应用程序中，可通过test command访问。这意味着用户可以随时运行测试而无需特殊设置。或者，如果您不喜欢在生产应用中运送测试，请使用CPP和cabal标志将它们仅包含在开发版本中，或者包含在单独的测试运行器可执行文件中。

还有功能测试，tests/目录中的每个文件中有一个或多个文件，与shelltestrunner一起运行，以及一些基于Makefile的与开发进程相关的测试。

来源

2011-01-14 23:21:28

为了完整起见，值得一提的是通过ghci -i为小项目提供一种非常简单的方法。例如，你的情况，

>ghci -isrc:testsuite 
ghci>:l Clue.Cards 
ghci>:l tests.Clue.Cards

来源

2013-08-10 00:50:26 Causality

组织Haskell测试

回答

相关问题