Я только что начал новый проект Haskell и с самого начала хотел создать хороший тестовый процесс. Похоже, у Haskell есть множество отличных и уникальных инструментов тестирования и множество способов их интеграции.
Я просмотрел:
Что все, кажется, работает очень хорошо в своих доменах, но я ищу всеобъемлющий подход к тестированию и задавался вопросом, что сработало хорошо для других людей.
Получение модульного тестирования, охвата кода и контрольных показателей в основном связано с выбором правильных инструментов.
Я буду использовать в качестве примера пример пакета, который я только начал включать с модульным тестированием, охватом кода и эталонами:
http://github.com/ekmett/speculation
Вы можете интегрировать свои тесты и тесты непосредственно в свой файл cabal, добавляя для них разделы и маскируя их за флагами, чтобы они не делали так, чтобы каждый пользователь вашей библиотеки имел доступ (и хотел используйте для себя) точную версию инструментов тестирования, которые вы выбрали.
http://github.com/ekmett/speculation/blob/master/speculation.cabal
Затем вы можете сказать кабалу о том, как запустить тестовый пакет. Поскольку тест кабала еще не существует - у нас есть студент, который работает над этим летом этого года! - лучший механизм, который у нас есть, - это. Вот как использовать механизм крюка пользователя cabal. Это означает переход на "Custom" сборку с помощью cabal и создание testHook. Пример testHook, который запускает тестовую программу, написанную с помощью тестовой среды, а затем применяет hpc к профилю, можно найти здесь:
http://github.com/ekmett/speculation/blob/master/Setup.lhs
И затем вы можете использовать тестовую инфраструктуру для объединения тестов QuickCheck и HUnit в одну программу:
http://github.com/ekmett/speculation/blob/master/Test.hs
В кэшированном файле обязательно включить -fhpc, чтобы включить тестирование покрытия кода, а затем testHook в Setup.lhs вручную запускает hpc и записывает свой вывод в ваш каталог dist.
Для бенчмаркинга история немного более ручная, нет опциона "cabal benchmark". Вы можете связать свои тесты с тестовым кликом, но мне нравится запускать их вручную, так как Criterion имеет так много графических параметров отчетности. Вы можете добавить свои тесты в файл cabal, как показано выше, дать им отдельные флаги компиляции, скрыть их за флаг cabal, а затем использовать Criterion для выполнения всего тяжелого подъема:
http://github.com/ekmett/speculation/blob/master/Benchmark.hs
Затем вы можете запустить свои тесты из командной строки и получить всплывающие окна KDE с результатами тестов и т.д.
Так как на практике вы живете в кабале в любом случае при разработке кода Haskell, имеет смысл интегрировать вашу инструментальную цепочку с ней.
Изменить. Поддержка тестирования Cabal теперь существует. См. http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/developing-packages.html#test-suites
Этот подход является сторонником RWH ch 11 и XMonad:
Как только ваши основные инварианты установлены с помощью QuickCheck, вы можете начать рефакторинг, переместив эти тесты в инварианты типов.
Практикуйте свои усилия:
Пакет test-framework действительно потрясающий. Вы можете легко интегрировать тесты HUnit и QuickCheck и получать исполняемые файлы, которые запускают только определенные пакеты, на основе флагов командной строки, с несколькими целями вывода.
Тестирование и профилирование - это разные звери. Для профилирования я создал отдельный исполняемый файл, который подчеркивает только раздел, который вы хотите профилировать, и просто внимательно изучайте результаты профилирования сборок и запусков (с -prof-auto-all для компиляции и + RTS -p для среды выполнения флаг).
Для тестирования я полагаюсь на свойства HUnit и QuickCheck и использую Haskell Test Framework, чтобы автоматически собирать все модульные тесты и все свойства QuickCheck.
Отказ от ответственности: я являюсь основным разработчиком тестовой платформы Haskell.