Организация тестов на Haskell

Question

Итак, я пытаюсь следовать предложенной структуре проекта 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.

Answer 1

Я использую подход, принятый Snap Framework для их наборов тестов, который в основном сводится к:

1. Использование тест-фреймворка, такого как haskell-test-framework или HTF

2. Назовите модули, содержащие тесты, добавив .Tests к имени модуля, содержащему IUT, например:

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

3. Используя отдельные пространства имен, вы можете поместить свои тесты в отдельную исходную папку tests/, затем вы можете использовать отдельную цель сборки Cabal (см. Также cabal test -build-targetподдержка в последних версиях Cabal) для комплекта тестов, который включает в себя дополнительную исходную папку в настройке hs-source-dirs, например:

   Executable clue
     hs-source-dirs: src
     ...
   
   Executable clue-testsuite
     hs-source-dirs: src tests
     ...
   

   Это работает, так как между модулями в вашем IUT и между пространствами имен нет конфликтовтестовый набор больше.

Answer 2

Вот еще один способ:

Модульные тесты каждого модуля определяются как hunit TestList в конце модуля с некоторой последовательной схемой именования, такой как "tests_Path_To_Module". Я думаю, что это помогает мне писать тесты, так как мне не нужно искать другой модуль далеко в дереве исходного кода или синхронизировать две параллельные файловые иерархии.

Список тестов модуля также включает тесты любых подмодулей. RunTunTT RunT от Hunit встроен в приложение и доступен через тестовую команду . Это означает, что пользователь может запустить тесты в любое время без специальной настройки. Или, если вам не нравятся тесты доставки в производственном приложении, используйте флаги CPP и cabal, чтобы включать их только в сборки dev или в отдельный исполняемый файл runner.

Существуют также функциональные тесты, по одному или более на файл в каталоге tests / , выполняемые с shelltestrunner , и некоторые тесты, связанные с процессом разработки, основанные на Makefile.

Answer 3

Лично я чувствую, что дополнительный каталог ./src/ не имеет особого смысла для небольших проектов на Haskell.Грубый источник, я скачал исходный код.

В любом случае (с или без src), я бы предложил вам рефакторинг и иметь каталог Clue и каталог Test:

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

Это позволяет GHCi + Test.Cards видеть Clue.Cards без каких-либо дополнительных аргументов или использования клики.На этой ноте, если вы не используете cabal + flags для необязательной сборки ваших тестовых модулей, тогда вам следует изучить это.

Другой вариант, который я использую во многих моих проектах, должен иметь:

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

И я cabal install пакет, затем запускаю tests/someTests.hs.Полагаю, это было бы неприятно, если бы мои пакеты были особенно большими и слишком длинными для установки.

Answer 4

Для полноты картины стоит упомянуть очень легкий подход для небольшого проекта через ghci -i.Например, в вашем случае,

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