Я щойно розпочав новий проект Haskell і з самого початку хотів налаштувати хороший тестовий робочий процес. Схоже, Haskell має безліч чудових та унікальних інструментів тестування та безліч різних способів їх інтеграції.
Я переглянув:
Які, здається, дуже добре працюють у своїх областях, але я шукаю комплексний підхід до тестування і цікавився, що добре працює для інших людей.
Відповіді:
Правильне тестування одиниць, покриття коду та орієнтирів - це здебільшого підбір правильних інструментів.
Я буду використовувати в якості прикладного пакету пакет, який я щойно почав включати в тестування одиниць, покриття коду та орієнтири:
http://github.com/ekmett/speculation
Ви можете інтегрувати свої тести та орієнтири безпосередньо у свій файл кабалу, додаючи до них розділи та маскуючи їх під прапорами, щоб вони не зробили так, що кожен користувач вашої бібліотеки повинен мати доступ (і хоче використовувати для себе ) точну версію обраних інструментів тестування.
http://github.com/ekmett/speculation/blob/master/speculation.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 і записує свій вихід у ваш дистрибутив.
Для бенчмаркінгу історія трохи більше посібника, не існує варіанту «кабального орієнтиру». Ви можете підключити свої орієнтири до тестового гака, але я люблю запускати їх вручну, оскільки в Критерії є дуже багато варіантів графічного звітування. Ви можете додати свої орієнтири до файлу кабалу, як показано вище, надати їм окремі прапорці компіляції, заховати їх за прапором кабалу, а потім використати критерій, щоб зробити всі важкі підйоми:
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
cabal testі cabal bench, змішуючись HUnit, doctestі quickcheckтести , засновані з criterionкритеріями. Код у speculationпопередніх cabal testта cabal bench.
Підхід є прихильником у RWH ch 11 і в XMonad приблизно:
Як тільки ваші основні інваріанти будуть встановлені за допомогою QuickCheck, ви можете розпочати рефакторинг, перемістивши ці тести на інваріанти типу.
Практики для підтримки ваших зусиль:
Пакет тестових рамок дійсно приголомшливий. Ви можете легко інтегрувати тести HUnit і QuickCheck і отримувати виконуючі файли, які виконують лише визначені набори, засновані на прапорах командного рядка, з кількома вихідними цілями.
Проте тестування та профілювання - це різні звірі. Для профілювання я створив окремий виконуваний файл, який підкреслює лише той розділ, який ви хочете профайлювати, і просто уважно переглядаючи результати побудови та запуску профілю (з -prof-auto-all для компіляції та + RTS -p під час виконання прапор).
Для тестування я покладаюся на властивості HUnit та QuickCheck і використовую Haskell Test Framework щоб автоматично збирати всі тестові одиниці та всі властивості QuickCheck.
Відмова: Я є головним розробником тестової системи Haskell.
cabal benchзараз існує також.