Pull to refresh

Comments 7

Говорят, что плохое запоминается лучше. Так и я помню, что scalacheck игнорирует ограничения диапазона значений. Задаёшь ты ему _Gen.choose(1,1000)_, а он тебе генерирует 0 и ловит exception. Разработчики сказали, что так и задумано, и если не хочешь ловить 0, надо добавлять явную фильтрацию нулевых значений.

Статья как-то внезапно обрывается… Примеры создания генераторов приведены, а как их использовать, не показано. Да, я могу сам сходить в гугл и поглядеть, но всё же хотя бы один пример не помешал бы, для порядка.

Статья как-то внезапно обрывается…

А это я вас так заинтриговал ;) В следующей части как раз будет рассказано о генераторах в том числе с примерами их использования.

Shrinking я бы перевел как «сокращение»

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


«Свойство-ориентированное тестирование», хотя и является формально верной калькой с английского «property-based testing», звучит и выглядит ужасно. Возможно, следовало бы оттолкнуться от альтернативного термина «generator-driven testing» и воспользоваться описательным переводом. Как по мне, самым подходящим названием было бы «эвристически-рандомизированное тестирование».

Паша, полностью тебя поддерживаю. И я также недоволен оригинальным термином. Generator-driven testing более соответствует действительности нежели property-based. Но, к сожалению вопрос по оригинальной терминологии следует задавать John Hughes. Я перевел данный термин как точную кальку для того, чтобы не вводить в заблуждение читателей. Есть ли те кто считает, что оригинальный термин подобран не корректно? Я бы хотел услышать ваше мнение.

Насколько я понимаю, в ScalaCheck ключевым является понятие "свойства". А генераторы используются постольку поскольку, как средство, позволяющее убедиться, что свойство выполняется в широком диапазоне значений.
ScalaCheck не подходит для замены Unit-тестов во всех случаях. Этот подход прекрасно работает тогда, когда удаётся найти те самые свойства, справедливые для многих случаев. Если программа представляет собой много отдельных несвязанных случаев — switch/case/if, то маловероятно, что такие обобщённые свойства будет легко обнаружить. А вот если тестируется универсальный алгоритм, то мы можем ожидать определённой стабильности его результатов.
Если термин "свойство-ориентированное тестирование" не нравится, то можно поискать альтернативы для слова "свойство". Например, "инвариант" — тестирование на основе инвариантов. Или "предикат" — тестирование на основе валидации предикатов. Или "ограничение" — проверка ограничений, тестирование ограничений.

Sign up to leave a comment.

Articles