Использовали ли вы Quickcheck в реальном проекте [закрыт]

Question

Быстрая проверка и его варианты (даже есть один в Java - Язык), кажется интересным.Однако, помимо академического интереса, действительно ли это полезно при тестировании реального приложения (например.приложение с графическим интерфейсом или клиент / сервер или даже взять сам StackOverflow)?Мы ценим любой опыт, который у вас был с подобными генераторами тестов.

Answer 1

Да, хорошо.На самом деле нет, но я учился у человека, который изначально разработал QuickCheck, и он действительно интересный парень.

Еще в 2004 году мы были вынуждены использовать QuickCheck для тестирования наших программ на Haskell, и это было сочетание хорошего и плохого.В основном плохо, потому что Haskell сам по себе был немного пугающим, но от этого не менее замечательным, когда вы заставляли его работать.

С тех пор Джон усовершенствовал то, что написал много лет назад, и фактически помог Ericssion протестировать их сложное телекоммуникационное оборудование, и он обнаружил ошибки примерно в 20 миллионах строк кода, сократив этот процесс до трех шагов благодаря своему подходу.Он отличный оратор, поэтому всегда приятно слушать, как он рассказывает о том, что у него так хорошо получается, но в целом то, что он сделал с QuickCheck, было для меня в новинку.Поэтому я спросил его, в чем его интерес в том, чтобы вывести это на рынок.Он был открыт для этой идеи, но в то время его бизнес (основанный на QuickCheck) был относительно новым, и поэтому были другие области, на которых он мог бы сосредоточиться.Сейчас 2007 год.Я хочу сказать, что вы могли бы извлечь уроки из QuickCheck, даже если в конечном итоге вы не будете им пользоваться.

Но что такое QuickCheck?Это платформа комбинаторного тестирования и интересный способ тестирования программ.Сотрудники Microsoft Research создали Пекс что в некотором роде похоже.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%.

Answer 2

Я выполнил реальную задачу Haskell, которая включала в себя моделирование дискретных событий.Итак, я написал библиотеку DES, основанную на монаде продолжения, наряду с эквивалентами MVAR'ов и каналов.Мне нужно было проверить, что это работает должным образом, поэтому я написал кучу свойств быстрой проверки, чтобы продемонстрировать, что, например, два потока одновременных данных, записанных на Канал, будут корректно объединены без удаления чего-либо.

Я также использовал QuickCheck для документирования и проверки свойств в моем Ранжированные Наборы и Десятичная дробь библиотеки.

По моему опыту, быстрая проверка иногда полезна.Если вы можете кратко описать важное свойство, хотя алгоритм, обеспечивающий это свойство, является сложным, то QuickCheck - это огромный выигрыш.С другой стороны, я часто нахожу, что алгоритм эквивалентен свойству, которое я хочу проверить.В этом случае я ищу более простые свойства.Например, предположим, что функция "foo" должна быть не строго монотонной.Тогда вы можете написать

prop_fooMonotonic x y = (x > y) ==> (foo x >= foo y)

Answer 3

Я использую QuickCheck для многих личных вещей.В течение последних шести месяцев:

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

• Запустил QuickCheck, чтобы протестировать модуль символьного дифференцирования, который я создал на скорую руку для некоторой числовой оптимизации.

• Запустил QuickCheck, чтобы протестировать дерево троичного поиска в стиле Bentley и Sedgewick.

Быстрая проверка редко встречается ВСЕ мне нужно модульное тестирование, но это отличный способ начать - а законы QuickCheck создают хорошую документацию.

Answer 4

Я использовал его довольно часто, в основном прямолинейно, в основном для тестирования реализаций протоколов и синтаксических анализаторов.

Однако вот менее тривиальный отрывок из моего личного опыта: http://www.haskell.org/haskellwiki/QuickCheck_as_a_test_set_generator

Answer 5

Проверка масштаба (быстрая проверка для Scala) используется для тестирования Функциональная Java, библиотека, которая, помимо прочего, реализует быстрая проверка для Java.

Answer 6

AFAIK XMonad тщательно тестируется с помощью QuickCheck

Answer 7

Я использовал Haskell только в производственной среде для разработки небольших вспомогательных инструментов.Главным образом потому, что я единственный известный мне разработчик, который читает Haskell.Однако я широко использовал QuickCheck и был очень раздражен тем, что нечто подобное недоступно в C #.Поэтому я решил попробовать и напиши это сам.Я тоже посмотрел на Pex, но обнаружил, что методы исследования программы, которые используются для поиска минимального ввода, менее интересны, чем то, как это делает QuickCheck.

Answer 8

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

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

Для удобства я написал http://hackage.haskell.org/package/proctest, который включает в себя несколько примеров QuickCheck, используемых вместе с hspec и HUnit для тестирования программ командной строки таким образом.

Answer 9

Мы используем Проверка FsCheck чтобы проверить правильность наших переводов OCaml в F # и то, что наши оптимизированные версии работают так же, как и неоптимизированные версии.Я также планирую использовать его для тестирования лексера и синтаксического анализатора, поскольку НХол проект использует анализатор комбинатор.

У нас также есть вспомогательные функции, которые позволяют нам запускать тест внутри НАнит (xUnit для .Net).Видишь ассертПроп.

Answer 10

Я использовал QuickCheck для тестирования кодировщика и декодера SMS PDU в мобильной платформе LG Linux.(Старая) версия программного обеспечения, которое я разработал в то время, доступна для скачивания по адресу http://hackage.haskell.org/package/GenSmsPdu-0.1

Answer 11

Это не мой проект, но containers пакет довольно широко использует QuickCheck.Лично я попытался использовать его для сравнения глупого маленького простого сита, которое я написал, с одним из arithmoi, что привело меня к открытию этого в arithmoi иногда сбои в сегментах.