Это видео проходило в Erlang Questions, Scala Lounge, Lambda The Ultimate, но не все их читают, поэтому спешу поделиться ссылкой на презентацию Джона Хьюза Functional Programming — A Secret Weapon for Software Testing (video 59mins) (примерно час, 200 Мбайт). В ней он рассказывает о расширенной версии хаскелевского QuickCheck написанной Quviq AB (Хьюз CEO компании) на Эрланге. В довольно увлекательной и забавной манере он рассказывает о сути этого, довольно уникального, инструмента тестирования и о том, почему выбрали функциональный язык и именно Эрланг. Улыбнул момент "почему не хаскель":

...we don't have that pesky type system...

Rickard Nilsson в своём комментарии в Scala Lounge упомянул, что ScalaCheck тоже умеет делать test case shrinking, но пока там нет конечных автоматов как у Quviq, но в ближайшей версии кое-что подобное планируется. Стоит отметить, что Хьюз упоминает конечные автоматы как одно из наиболее значимых расширений "классического" QuickCheck.

Здравствуйте, Курилка, Вы писали:

К>Rickard Nilsson в своём комментарии в Scala Lounge упомянул, что ScalaCheck тоже умеет делать test case shrinking, но пока там нет конечных автоматов как у Quviq, но в ближайшей версии кое-что подобное планируется. Стоит отметить, что Хьюз упоминает конечные автоматы как одно из наиболее значимых расширений "классического" QuickCheck.

А что это за расширение?

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, Курилка, Вы писали:

К>>Rickard Nilsson в своём комментарии в Scala Lounge упомянул, что ScalaCheck тоже умеет делать test case shrinking, но пока там нет конечных автоматов как у Quviq, но в ближайшей версии кое-что подобное планируется. Стоит отметить, что Хьюз упоминает конечные автоматы как одно из наиболее значимых расширений "классического" QuickCheck.

L>А что это за расширение?

Ну вот обычные тесты записываются наборами тестов и утверждеий. Т.е. по сути последовательность действий линейная.
А там что-то типа того, что записываешь автомат, который должен моделировать поведение системы, ну и опять же с утверждениями, которые должны соблюдаться. По меньшей мере я настолько понял. Руками их продукт потрогать нельзя (на сайте даж линка нет куда обратиться чтоб купить), инфы публичной тоже кот наплакал
Кстати я не читал, но может вот это тоже от Хьюза тебе будет интересно, про тестирование монад

Здравствуйте, Курилка, Вы писали:

К>Ну вот обычные тесты записываются наборами тестов и утверждеий. Т.е. по сути последовательность действий линейная.

Утверждение — это не линейная последовательность действий.

например prop_ConsLength x xs = length xs + 1 == length (x:xs)

Это типичный property для QuickCheck в Haskell.

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

Вот при автомат интересно, что имеется в виду.

К>По меньшей мере я настолько понял. Руками их продукт потрогать нельзя (на сайте даж линка нет куда обратиться чтоб купить), инфы публичной тоже кот наплакал

Жалко

К>Кстати я не читал, но может вот это тоже от Хьюза тебе будет интересно, про тестирование монад

Угу, спасибо, почитаю, только это по моему не то.

Здравствуйте, lomeo, Вы писали:

L>Утверждение — это не линейная последовательность действий.

L>например prop_ConsLength x xs = length xs + 1 == length (x:xs)

L>Это типичный property для QuickCheck в Haskell.

И что тут нелинейного? Есть входы, есть выходы, они сравниваются, всё.

L>Вот при автомат интересно, что имеется в виду.
Посмотри видео, может лучше меня поймёшь — мне объяснишь
Имхо там получается, что ты описываешь не просто входы/выходы функции с зависимостями между ними (утверждениями), а строишь автомат, который получается типа графа из этих самых функций, связанных входами/выходами.

К>>По меньшей мере я настолько понял. Руками их продукт потрогать нельзя (на сайте даж линка нет куда обратиться чтоб купить), инфы публичной тоже кот наплакал
L>Жалко
Да вообще, помнится полгода назад уже нарывался на их сайт, думал письмо написать — типа дайте хоть что-нибудь поглядеть, интересно же. Но лень переборола.

К>>Кстати я не читал, но может вот это тоже от Хьюза тебе будет интересно, про тестирование монад
L>Угу, спасибо, почитаю, только это по моему не то.
Ну я понимаю, что нето, просто несколько по теме и может быть интересно.

Здравствуйте, Курилка, Вы писали:

К>И что тут нелинейного? Есть входы, есть выходы, они сравниваются, всё.

Акцент не там. Это не линейная последовательность действий, в смысле это вообще не последовательность действий

К>Посмотри видео, может лучше меня поймёшь — мне объяснишь
К>Имхо там получается, что ты описываешь не просто входы/выходы функции с зависимостями между ними (утверждениями), а строишь автомат, который получается типа графа из этих самых функций, связанных входами/выходами.

ОК, вечерком.

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, Курилка, Вы писали:

К>>И что тут нелинейного? Есть входы, есть выходы, они сравниваются, всё.

L>Акцент не там. Это не линейная последовательность действий, в смысле это вообще не последовательность действий

Ну да, наверное про последовательность это не совсем корректный термин, тем более для декларативных языков
Суть наверное в другом — традиционно ты делаешь отдельные утверждения, может быть конечно составленные при помощи лог. операций из более мелких утверждений.
Для автомата же ты задаёшь систему таких утверждений и переходы от одного к другому. Получается в итоге императивная вещь, автоматы они ведь обладают состоянием. В итоге получается более крупномасштабное тестирование, чтоли, причём shrinking должен дать те исходные данные, которые привели к багу, если таковой обнаружен, получаем обнаружение причин наведённых ошибок.

Здравствуйте, Курилка, Вы писали:

К>Ну да, наверное про последовательность это не совсем корректный термин, тем более для декларативных языков
К>Суть наверное в другом — традиционно ты делаешь отдельные утверждения, может быть конечно составленные при помощи лог. операций из более мелких утверждений.
К>Для автомата же ты задаёшь систему таких утверждений и переходы от одного к другому. Получается в итоге императивная вещь, автоматы они ведь обладают состоянием. В итоге получается более крупномасштабное тестирование, чтоли, причём shrinking должен дать те исходные данные, которые привели к багу, если таковой обнаружен, получаем обнаружение причин наведённых ошибок.

не понял, а что мешает сделать prop_... в котором и будет задаваться любая последовательность действий (помоему это будет более читабельно чем автомат)? и shrinking в хаскелевской версии есть, для состояния в генераторе можно написать трансформер который бы состояние добавлял,
для свойств можно использовать уже готовый liftIOResult :: IO Result -> Property.

ввиду того что эрланг не знаю жду что кто-то знающий посмотрит ролик и скажет что же там в эрланговской версии нового добавилось.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Курилка, Вы писали:

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

А>не понял, а что мешает сделать prop_... в котором и будет задаваться любая последовательность действий (помоему это будет более читабельно чем автомат)? и shrinking в хаскелевской версии есть, для состояния в генераторе можно написать трансформер который бы состояние добавлял,
А>для свойств можно использовать уже готовый liftIOResult :: IO Result -> Property.

Дак shrinking изначальнож сказано было из Хаскеля, а автоматы примерно тоже самое и представляют — такое сложное утверждение. Насколько я понимаю в оригинальном quickcheck'е их не было (хотя я его не знаю, поэтому не могу утверждать об этом точно).

А>ввиду того что эрланг не знаю жду что кто-то знающий посмотрит ролик и скажет что же там в эрланговской версии нового добавилось.

Да там особо подробно не показано, так что не имея возможности "попробовать" получаются больше догадки

QuickCheck с навороченной логикой на автоматах — уже не будет QuickCheck'ом...
Суть-то QuickCheck'а в том, что бы быстренько наляпать простеньких тестов и проверить, то ли вообще делает проверяемая функция...
А тест логики приложения — вряд ли будет быстрым. Пока там эту логику внесёшь в автоматы — повторишь половину функциональности самого приложения... :о))

Здравствуйте, geniepro, Вы писали:

G>QuickCheck с навороченной логикой на автоматах — уже не будет QuickCheck'ом...
G>Суть-то QuickCheck'а в том, что бы быстренько наляпать простеньких тестов и проверить, то ли вообще делает проверяемая функция...
G>А тест логики приложения — вряд ли будет быстрым. Пока там эту логику внесёшь в автоматы — повторишь половину функциональности самого приложения... :о))

Ты тож ещё не смотрел видео?
Там речь идёт о том, что как раз цель-то ставится автором другая, это не юнит-тесты, которые быстрые, мелкие и т.п.
Там как раз тестируют системы, а для тестирования сложной системы надо попыхтеть.
Как пример: на Эрланге они там тестируют гетерогенную систему, основные компоненты которой на плюсах, а в результате вылезают явовские исключения Как именно не знаю — наверное что-нибудь в логах/сообщениях об ошибках.
Оказалось — админка на яве, оттуда ноги у проблем росли.