Отрицательные тесты на основе свойств

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

Мне также повезло с «отрицательными свойствами» в случае тестирования парсеров, например. путем создания недопустимых идентификаторов или несоответствия отступов для языков, чувствительных к отступам. Но являются ли «отрицательные свойства» обычной вещью для выражения и проверки? Это означает написание генераторов, которые производят специализированные фиктивные входные данные.

Какие есть реальные примеры отрицательных свойств, не связанных с парсерами?


tdd quickcheck property-based-testing fuzz-testing fscheck
person Simon Shine    schedule 27.11.2015    source источник
comment
Хотелось бы услышать, что вы изменили за последний год (с момента публикации) в отношении тестирования отрицательных свойств.   -  person Zac    schedule 11.01.2017

Ответы (1)


arrow_upward
2
arrow_downward

У меня по сути тот же вопрос.

Я опубликовал его более подробно вместе со всеми своими мыслями о том, как это можно сделать:

Шаблон для создания отрицательных сценариев Scalacheck: использование тестирования на основе свойств для проверить логику проверки в Scala

Для нас ситуация «реального мира» заключается в том, что у нас есть большие классы дел с привязкой к данным, и эти классы дел имеют логику проверки (мы используем Wix Accord для проверки). Чтобы тщательно протестировать логику проверки, нам нужно создать объект, аннулировать одно из его свойств и посмотреть, не сработает ли validate(o). Затем повторите для каждого свойства объекта.

Мы также сталкиваемся с конкретными случаями, когда определенное свойство должно быть недействительным. Например, проверить, правильно ли наша система обработает недопустимый идентификатор. Это проще, мы можем просто использовать forAll(someGen) и мутировать его. По сути, просто v => val invalidV = v copy(id = "badID"), и теперь для каждого сгенерированного свойства я изменил его, чтобы он имел плохой идентификатор. Можно конечно пофантазировать, но суть понятна.

Все это кратко изложено в моем другом посте... вместе с открытым поиском «лучшего шаблона». Надеюсь на хорошие идеи!

person Zac    schedule 11.01.2017