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

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

Я изучил:

• HUnit
• Быстрая проверка
• жим лежа
• HPC
• сложность

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

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

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

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

http://github.com/ekmett/speculation

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

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

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

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

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

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

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

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

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

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

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

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

Подход пропагандируется в RWH ch 11, а в XMonad примерно так:

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

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

Практики, поддерживающие ваши усилия:

• Выполняйте упрощенную регрессию QuickCheck для каждой фиксации.
• Опубликуйте подробную информацию о покрытии HPC.

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

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

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

Отказ от ответственности: я являюсь основным разработчиком Haskell Test Framework.