Каждый автоматизатор сталкивается с задачей генерации тестовых данных. Кто-то генерит их в полуручном режиме (раз, два, три). Кто-то использует различные библиотеки (раз, два, три, четыре). А кто-то вообще не парится и хардкодит данные прямо в тестах. Я же хочу поделиться своим “велосипедом”.
Решение
Cases библиотека для генерации тестовых данных. Понятное дело, что мне не хватало именно такой библиотечки . Она предоставляет всего 4 основных метода:
cases.get_each_choice
cases.get_negative
cases.get_pairwise
cases.get_one
Здесь можно посмотреть примеры. Все методы, кроме последнего, возвращают генератор, который, в свою очередь, будет возвращать набор объектов. Каждый из объектов представляет 1 тестовый случай. Для генерации тестовых случаев используется дефолтный класс. При желании можно использовать свой класс, передав его первым аргументом в любой из методов.
На текущий момент реализация “устаканилась”. Пришла пора поделиться с сообществом и получить обратную связь.
Вобще с этой задачей отлично справляются фазеры. Я конечно тоже предпочитаю использовать свои решения, но иногда описывать все варианты мутаций входных данных очень накладно по времени, так что можно обращаться к Burp Suite, xmlfuzzer, powerfuzzer… Кто не брезгует целостностью мозга может пробовать микрософтовский FuzzGuru
Все-таки основная задача фазеров - это поиск уязвимостей. Поэтому использовать их для обычного тестирования в agile-проекте да еще и на этапе создания первой версии не совсем правильно, на мой взгляд.
Не понимаю, почему так много людей на этом форуме имеют понятие “обычное тестирование” и “необычное тестирование”, в одном из которых обращают внимание на ошибки уязвимости, а во втором нет. Я придерживаюсь мнения что тест изначально должен быть наиболее полным, а разработчики должны менять код, пока этот тест не будет успешно выполнен.
Что тут непонятного. Или ты не встречал ситуаций, когда релизить надо срочно? В такой ситуации приходится выпускать не отполированный до блеска функционал, а то, что есть, но максимально возможного качества, которого можно добиться в таких условиях.
Здесь и пригождается умение отделять зерна от плевел, а мух от котлет и тестировать в условиях жесткой приоритезации проверок. Тут уже не до фазеров и уязвимостей - успеть бы проверить успешные сценарии и минимальную защиту от дурака
Встречал, и быстро увольнялся из тех компаний, которые релизились в подобных ситуациях (в моем списке 3 компании (проекта) из 6, которые к релизу подходили правильно). Релизить что-то сделав лишь поверхностное тестирование - мягко говоря “неправильно”. Тем более если это что-то - входные параметры.