Рабочий процесс тестирования на Haskell

Question

Я только начал новый проект на Haskell и хотел с самого начала настроить хороший рабочий процесс тестирования.Похоже, у Haskell есть много отличных и уникальных инструментов тестирования и много разных способов их интеграции.

Я изучил:

• HUnit
• QuickCheck
• жим
• HPC
• сложность

Кажется, что все они работают очень хорошо в своих областях, но я ищу комплексный подход к тестированию, и мне было интересно, что хорошо работает для других людей.

Answer 1

Правильное модульное тестирование, охват кода и тесты - это, в основном, выбор правильных инструментов.

• test-framework предоставляет универсальный магазин для запуска всех ваших HUnit контрольные примеры и свойства QuickCheck из одного жгута.
• Покрытие кода встроено в GHC в виде инструмента HPC .
• Критерийпредоставляет довольно неплохое оборудование для бенчмаркинга

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

http://github.com/ekmett/speculation

Вы можете интегрировать свои тесты и тесты прямо в свой файл cabal, добавляя для них разделы и маскируя их под флагами, чтобы они не делали так, чтобы у каждого пользователя вашей библиотеки был доступ к (ихотите использовать для себя) точную версию инструментов тестирования, которые вы выбрали.

http://github.com/ekmett/speculation/blob/master/speculation.cabal

Затем вы можете сообщить Cabal о том, как запустить ваш набор тестов. Поскольку тест для каббалы еще не существует - у нас есть студент, работающий над ним для летнего кода этого года!- лучший механизм, который у нас есть, это Вот как использовать механизм хаба пользователя.Это означает переключение на «Custom» сборку с Cabal и настройку testHook.Пример testHook, который запускает тестовую программу, написанную с помощью test-framework, а затем применяет hpc к профилю, можно найти здесь:

http://github.com/ekmett/speculation/blob/master/Setup.lhs

И затем вы можете использовать test-каркас для объединения тестов QuickCheck и HUnit в одну программу:

http://github.com/ekmett/speculation/blob/master/Test.hs

В файле cabal осторожно включите -fhpc, чтобы включить тестирование покрытия кода, а затем testHook в программе установки..lhs вручную запускает hpc и записывает его вывод в ваш каталог дистрибутивов.

Для сравнительного анализа история немного более ручная, здесь нет опции 'cabal benchmark'.Вы могли бы привязать свои тесты к своему тестовому хуку, но мне нравится запускать их вручную, поскольку в Criterion так много вариантов графической отчетности.Вы можете добавить свои тесты в файл cabal, как показано выше, назначить им отдельные флаги компиляции, спрятать их за флагом cabal, а затем использовать Criterion для выполнения всей тяжелой работы:

http://github.com/ekmett/speculation/blob/master/Benchmark.hs

Затем вы можете запускать свои тесты из командной строки и получать всплывающие окна KDE с результатами тестов и т. Д.

Поскольку на практике вы все равно живете в cabal во время разработки кода на Haskell, это очень многоимеет смысл интегрировать ваш набор инструментов с ним.

Редактировать : поддержка тестирования Cabal теперь существует.См http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/developing-packages.html#test-suites

Answer 2

Подход защищен в RWH ch 11 и в XMonad приблизительно:

• Укажите все свойства системы в QuickCheck
• Показать тестовое покрытие с HPC.
• Подтверждение поведения пространства с помощью профилирование кучи .
• Подтверждение поведения потока / параллели с помощью ThreadScope .
• Подтвердите поведение микробенчмарка с помощью Критерий .

Как только ваши основные инварианты установлены с помощью QuickCheck, вы можете начать рефакторинг, переместив эти тесты в инварианты типов.

Практика поддержки ваших усилий:

• Запуск упрощенной регрессии QuickCheck для каждого коммита.
• Публикация сведений о покрытии HPC.

Answer 3

Пакет test-framework действительно потрясающий.Вы можете легко интегрировать тесты HUnit и QuickCheck и получать исполняемые файлы, которые запускают только указанные наборы, на основе флагов командной строки, с несколькими выходными целями.

Хотя тестирование и профилирование - это разные звери.Для профилирования я бы настроил отдельный исполняемый файл, который подчеркивает только тот раздел, который вы хотите профилировать, и просто внимательно смотрю на результаты профилирования сборок и прогонов (с -prof-auto-all для компиляции и + RTS -p для среды выполненияфлаг).

Answer 4

Для тестирования я использую свойства HUnit и QuickCheck и использую Haskell Test Framework , чтобы автоматически собирать все модульные тесты и все свойства QuickCheck.тестовой структуры Haskell.