Кратко — в чем разница
- Традиционные юнит‑тесты: пишешь конкретные входы и ожидаемые выходы (примерно «пример‑ориентированные»). Хороши для регрессий и документации поведения.
- Property‑based тестирование (QuickCheck): описываешь свойства/инварианты функции, а фреймворк генерирует множество случайных входов и пытается найти контрпример. Тесты проверяют общие свойства, а не отдельные случаи.
Ключевые отличия
- Генерация входных данных: вместо ручных примеров используются генераторы, покрывающие большой и неожиданный спектр входов.
- Обнаружение краевых случаев: случайная генерация + большая выборка находит редкие сочетания входов, которые можно легко пропустить вручную.
- Shrinking: при неудаче QuickCheck автоматически минимизирует контрпример до простого воспроизводимого случая.
- Способ мышления: проверяются логические свойства (инварианты, закономерности), а не отдельные вход‑выход пары.
- Статистическая природа: поведение теста задаётся количеством и стратегией генерации (тесты вероятностны, но детерминируемы по seed).
Примеры свойств (в сыром KaTeX)
- Сортировка: длина сохраняется: $\text{length}(xs)=\text{length}(\text{sort}xs)$.
Отсортированный результат действительно отсортирован: $\text{isSorted}(\text{sort}xs)$.
Результат — перестановка исходного массива (мультимножества равны).
- Обратимость: $\text{reverse}(\text{reverse}(xs))=xs$.
- Сериализация/десериализация: $\text{deserialize}(\text{serialize}(x))=x$.
- Ассоциативность/коммутативность (когда применимо): например $(a\oplus b)\oplus c=a\oplus (b\oplus c)$.
Задачи, где PBT даёт существенное преимущество
- Библиотеки работы со строками/байтами/потоками (входы разнообразны, много граничных случаев).
- Сериализация/парсинг/кодирование (коррупция данных, граничные форматы, скрытые символы).
- Алгоритмы и структуры данных (сохранение инвариантов, корректность после последовательности операций).
- Компиляторы/оптимизации/трансформации кода (сохранение семантики).
- Криптография и сжатие (инварианты обратимости/идентичности).
- Протоколы и состояния (состояний много; state‑machine testing расширяет PBT на сценарии).
- Замена ручного «фаззинга» — PBT часто находит ошибки, которые и ручные кейсы, и простые юнит‑тесты не обнаруживают.
Ограничения и предостережения
- Нужно проектировать хорошие генераторы и свойства — плохое свойство даёт ложное ощущение надёжности.
- Сложные stateful-системы труднее формализовать, но есть расширения (state machines).
- Тесты случайны по природе — важен контроль seed и reproducibility.
- Бывают «ложноположительные» провокации из‑за некорректно сформулированного свойства.
Рекомендация
- Используйте PBT для общих инвариантов и широкого покрытия входов; оставляйте юнит‑тесты для конкретных регрессионных случаев, документации и примеров использования.