Вы использовали Quickcheck в реальном проекте [закрыто]
Quickcheck и его варианты (даже есть один в Java), Кажется, интересно. Однако, помимо академического интереса, это действительно полезно в реальном тестировании приложения (например. приложение GUI или клиент / сервер или даже сам StackOverflow)? Любые опыты вы имели с подобными генераторами теста оценены.
11 ответов
Да, хорошо. Вообще-то нет, но я учился у человека, который изначально разработал QuickCheck, и он действительно интересный парень.
еще в 2004 году мы были вынуждены использовать QuickCheck для тестирования наших программ Haskell, и это было сочетание хорошего и плохого. В основном плохо, потому что Хаскелл был немного пугающим, но никогда не менее замечательным, когда вы заставили его работать.
Джон с тех пор усовершенствовал то, что он написал годы назад и фактически помог Ericssion проверить их сложное телекоммуникационное оборудование, и он нашел ошибки в 20 миллионах или около того строк кода, сократив это до трех шагов через его подход. Он отличный оратор, поэтому всегда приятно слушать, как он представляет то, что он делает так хорошо, но в целом, то, что он сделал с QuickCheck, было новым для меня. Поэтому я спросил его, что его интересует в том, чтобы принести это на рынок. Он был открыт для этой идеи, но в то время его бизнес (основанный на QuickCheck) был относительно новым, и поэтому были другие области, на которых он сосредоточится на. Это сейчас 2007. Я хочу сказать, что вы можете учиться у QuickCheck, даже если вы не будете использовать его.
но что такое QuickCheck? Это комбинаторная структура тестирования и интересный способ тестирования программ. Люди из Microsoft Research построили Pex что похоже на это. Pex генерирует тесты автоматически, изучая ваш IL. Однако Джон напишет генератор для возможных входных и тестовых свойств функции. Свойство-это то, что может быть легко протестирован, и это намного более формально. например, изменение списка? Ну, перевернуть список-это то же самое, что разбить список на две половины, перевернуть каждую по отдельности, а затем объединить две перевернутые половины в обратном порядке.
1,2,3,4 // original
1,2 3,4 // split into A and B
2,1 4,3 // reverse A and B
4,3,2,1 // concat B and A
Это отличное свойство для тестирования с помощью QuickCheck, называемой спецификацией, и результат довольно удивительный.
Pex приятно, но не так круто, как QuickCheck, Pex упрощает вещи, QuickCheck делает, но это требуется много усилий, чтобы написать хорошую спецификацию.
сила QuickCheck заключается в том, что когда он сталкивается с сбоем, он уменьшает вход, который вызвал сбой вашего теста, до минимально возможной формы. Оставляя вам подробное описание того, что прогрессирование состояния вызвало провал теста. По сравнению с другими фреймворками тестирования, которые просто попытаются сломать ваш код грубой силой.
Это стало возможным благодаря тому, как вы пишете свое тестирование спецификация. QuickCheck полагается на псевдослучайность, чтобы изобрести вход, и именно из-за этого он способен отследить и найти действительно небольшой вход, который не проходит ваш тест.
гораздо больше работы для записи свойств QuickCheck, но конечный результат-лучшее тестирование. Как сказал сам Джон, 70% ошибок пойманы модульным тестированием, но это другие 30%, которые вызывают сбой вашей программы. QuickCheck тестирует последние 30%.
Я сделал реальную проблему Haskell, которая включала моделирование дискретных событий. Поэтому я написал библиотеку DES, основанную на монаде продолжения, вместе с эквивалентами MVars и каналов. Мне нужно было проверить, что это работает правильно, поэтому я написал кучу свойств QuickCheck, чтобы продемонстрировать, что, например, два потока параллельных данных, записанных в канал, будут правильно объединены без удаления чего-либо.
Я также использовал QuickCheck для документирования и проверки свойства в моем Составляла Наборы и Decimal библиотеки.
по моему опыту QuickCheck иногда отлично. Если вы можете кратко суммировать важное свойство, хотя алгоритм, который предоставляет это свойство, является волосатым, то QuickCheck-огромная победа. С другой стороны, я часто нахожу, что алгоритм эквивалентен свойству, которое я хочу проверить. В таком случае я ищу более простые свойства. Например, предположим, что функция" foo " предполагается быть не строго монотонным. Тогда вы можете написать
prop_fooMonotonic x y = (x > y) ==> (foo x >= foo y)
Я использую QuickCheck для многих личных вещей. В течение последних шести месяцев:
Ran QuickCheck для тестирования цветовых преобразований и дискретных косинусных преобразований в компрессоре изображений.
Ran QuickCheck, чтобы проверить модуль символьного дифференцирования, который я взбил для некоторой численной оптимизации.
Ran QuickCheck для тестирования троичного дерева поиска в стиле Bentley и Седжвик.
QuickCheck редко встречается все мои потребности в модульном тестировании, но это отличный способ начать работу- - - и законы QuickCheck делают хорошую документацию.
Я использовал его довольно много, в основном прямолинейно, главным образом для тестирования протоколов и реализаций парсера.
однако, вот менее тривиальный бит из моего личного опыта:http://www.haskell.org/haskellwiki/QuickCheck_as_a_test_set_generator
ScalaCheck (быстрая проверка для Scala) используется для тестирования Функциональная Java, библиотека, которая, среди прочего, реализует быстрая проверка для Java.
Я использовал Haskell только в производственной среде для разработки небольших вспомогательных инструментов. В основном потому, что я единственный известный мне разработчик, который читает Хаскелла. Я широко использовал QuickCheck и очень раздражался, что что-то подобное недоступно в C#. Поэтому я решил попробовать и напиши сам. Я тоже посмотрел на Pex, но обнаружил, что методы исследования программы, которые используются для поиска минимального ввода, менее интересны, чем QuickCheck что.
Я использую QuickCheck для проверки поведения программ командной строки, написанные на любом языке.
особенно полезно найти входы, на которых происходит сбой низкоуровневых или динамически типизированных программ.
для удобства я написал http://hackage.haskell.org/package/proctest, который включает в себя некоторые примеры QuickCheck, используемые вместе с hspec и HUnit для тестирования программ командной строки таким образом.
мы используем:FsCheck чтобы проверить, что наши переводы OCaml на F# верны и что наши оптимизированные версии работают так же, как и неоптимизированные версии. Я также планирую использовать его для тестирования лексера и парсера с адррес nhol использует парсер комбинатора.
У нас также есть вспомогательные функции, которые позволяют нам запускать тест в Нанит (XUnit для .Net). См.assertProp.
Я использовал QuickCheck для тестирования кодировщика и декодера SMS PDU в мобильной платформе LG Linux. A (old) версия A piece of software I developed at that time доступна для скачивания наhttp://hackage.haskell.org/package/GenSmsPdu-0.1
Это не мой проект, но containers пакет использует QuickCheck довольно широко. Лично я попытался использовать его для сравнения глупого маленького простого сита, который я написал в arithmoi, что привело меня к открытию этого в arithmoi иногда segfaults.