組織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測試

回答

相關問題