Валидация принимает множество комбинаций входных данных, а ручной перебор примеров не выявляет редкие ошибки. Какой подход автоматизации следует применить?
Следует применить property-based testing — генерацию множества входных данных с проверкой общих свойств результата. В отличие от проверки заранее выбранных примеров, этот подход исследует пространство входов и помогает находить редкие комбинации, нарушающие инварианты.
Обычные автотесты чаще всего строятся вокруг примеров: задан конкретный вход, ожидаемый результат и отдельный сценарий. Такой подход хорошо проверяет известные бизнес-кейсы, но плохо покрывает большое количество комбинаций и неожиданные границы.
Property-based testing решает эту проблему за счёт описания правил, которым должен удовлетворять результат, и автоматической генерации входных данных. При обнаружении ошибки инструмент обычно сокращает найденный набор до минимального контрпримера, который проще анализировать.
Например, система сортирует, фильтрует или нормализует коллекции данных. Набор фиксированных тестов может проверить пустой список, несколько обычных элементов и один очевидный граничный случай, но не обнаружить ошибку на повторяющихся значениях, необычных размерах или особом сочетании параметров.
Если такие ошибки не проверять, они могут проявиться только на данных реального пользователя. Простое увеличение числа примеров частично помогает, но повышает стоимость поддержки и всё равно не гарантирует разнообразие входов.
Сначала формулируют свойство, а не конкретный ожидаемый ответ. Например, после сортировки результат должен быть упорядочен, содержать те же элементы, что и исходная коллекция, и иметь ту же длину.
Затем задают генераторы входов: диапазоны значений, размеры коллекций, допустимые комбинации и ограничения предметной области. Генератор создаёт множество случаев, а тест проверяет сформулированные свойства для каждого из них.
Важна проверка корректности самих генераторов. Если они создают только простые или нереалистичные данные, тест даст ложное ощущение широкого покрытия. Ограничения генерации должны отражать допустимые входы системы, а отдельные тесты должны проверять реакцию на невалидные данные.
При сбое полезен механизм shrinking — автоматическое уменьшение контрпримера. Например, вместо длинной коллекции инструмент может найти минимальный набор из двух элементов, на котором воспроизводится нарушение свойства.
Ограничение подхода в том, что он не заменяет сценарные тесты. Свойство может быть сформулировано слишком слабо и пропустить ошибку, а бизнес-процесс с конкретными правилами переходов состояний часто понятнее проверять фиксированными сценариями.
Практический компромисс — сочетать оба подхода: примерами проверять ключевые бизнес-правила и известные регрессии, а генерацией исследовать границы, комбинации и инварианты. Для нестабильных или дорогих операций также контролируют количество сгенерированных случаев, время выполнения и воспроизводимость случайного набора.
Команда тестировала преобразование пользовательских фильтров в запросы. Фиксированные тесты покрывали обычные поля и несколько операторов, но периодически возникала ошибка при сочетании пустых значений, отрицательных диапазонов и повторяющихся условий.
Рассматривались три варианта. Увеличение набора примеров было простым, но требовало постоянного ручного пополнения и не гарантировало поиск новых комбинаций. Полный перебор быстро стал бы слишком дорогим. Property-based testing позволил генерировать допустимые фильтры и проверять свойства преобразования: отсутствие потери условий, сохранение логической структуры и корректную обработку пустого результата.
Команда выбрала смешанную стратегию: фиксированные сценарии оставили для значимых пользовательских случаев, а генерацию добавили для комбинаций фильтров. Найденные контрпримеры после анализа превращали в постоянные регрессионные тесты, поэтому случайное исследование постепенно усиливало обычный набор проверок.
Нет. Количество случаев само по себе не гарантирует качества. Покрытие зависит от распределения генератора: редкий, но важный класс входов может почти не появляться. Поэтому оценивают классы данных и границы, задают ограничения, используют воспроизводимый seed и сохраняют найденные контрпримеры.
При fuzzing основной акцент часто делается на поиске сбоев, например аварийного завершения, тайм-аутов или нарушений безопасности, иногда с минимальными знаниями о корректном результате. Property-based testing требует явно заданных свойств, которым должен удовлетворять результат. Подходы могут дополнять друг друга: fuzzing ищет неожиданные отказы, а property-based testing проверяет инварианты предметной области.
Используют оракулы, не требующие заранее вычислять точный ответ. Это могут быть инварианты, отношения между несколькими запусками, эталонная более простая реализация или свойства идемпотентности. Например, повторное применение нормализации может не менять уже нормализованный результат. Если проверка опирается на ту же ошибочную логику, что и тестируемый код, генерация не устранит риск общего дефекта.