Тесты на примерах проверяют те случаи, до которых вы додумались. Property-based тесты проверяют тысячи случаев, до которых вы НЕ додумались, — и при падении сами ужимают вход до минимального контрпримера. Разбираем, как это работает под капотом, какие свойства бывают, и показываем на коде (Python/Hypothesis), как PBT за минуту находит баг, который ручной тест-кейс не нашёл бы никогда.
Классический unit-тест — это «вход X → ожидаю Y». Вы придумали кейс, зафиксировали ожидание, поехали. Проблема в том, что баги обычно живут не в кейсах, которые вы придумали, а ровно в тех, до которых не дотянулась фантазия: пустая строка, эмодзи, дубликаты, отрицательный ноль, перевод строки внутри значения, целочисленное переполнение.
Property-based testing (PBT) переворачивает подход: вы описываете свойство — утверждение, которое должно быть истинно для любого корректного входа, — а фреймворк сам генерирует сотни случайных входов и пытается это свойство опровергнуть. Нашёл контрпример — ужимает его до минимального («shrinking») и показывает вам.
Пример на примерах vs свойство
Тест на примерах для функции сортировки:
def test_sort_example():
assert my_sort([3, 1, 2]) == [1, 2, 3]Один вход, одно ожидание. А вот свойства, которые верны для любого списка:
from hypothesis import given, strategies as st
@given(st.lists(st.integers()))
def test_sort_keeps_length(xs):
assert len(my_sort(xs)) == len(xs) # длина не меняется
@given(st.lists(st.integers()))
def test_sort_is_ordered(xs):
r = my_sort(xs)
assert all(r[i] <= r[i + 1] for i in range(len(r) - 1)) # реально отсортировано
@given(st.lists(st.integers()))
def test_sort_is_permutation(xs):
assert sorted(my_sort(xs)) == sorted(xs) # это перестановка исходного, ничего не потеряли/не добавили@given(...) запускает каждый тест на сотне+ сгенерированных списков: пустых, из одного элемента, с дубликатами, с MIN_INT/MAX_INT, гигантских. Вам не нужно придумывать эти кейсы — генератор делает это за вас.
Как это работает под капотом
Три кирпича:
1. Генераторы (strategies) — описывают пространство входов: st.integers(), st.text(), st.lists(...), st.dictionaries(...), и комбинации.
2. Свойство — булево утверждение, которое должно держаться для всех входов из этого пространства.
3. Shrinking — когда свойство падает на каком-то монструозном случайном входе, фреймворк автоматически ищет минимальный вход, на котором оно всё ещё падает.
Именно shrinking превращает PBT из «рандомного фаззера» в инструмент отладки. Сравните два сообщения о падении:
# без shrinking — попробуй пойми, что тут сломалось:
Falsifying example: s = 'a8Q\x00\udce2\n\t ZZ9📦\r\x7f...(2000 символов)'
# с shrinking — Hypothesis ужал до минимума:
Falsifying example: test_roundtrip(s='\n')Во втором случае сразу видно: баг в обработке перевода строки. Это и есть киллер-фича.
Каталог свойств: что вообще утверждать
Самое сложное в PBT — не код, а придумать свойство. Хорошая новость: есть готовые паттерны, которые покрывают большинство случаев.
1. Round-trip (туда-обратно). Самый мощный и частый. decode(encode(x)) == x: сериализация/парсинг, кодеки, JSON, URL-энкодинг, сжатие.
@given(st.text())
def test_json_roundtrip(s):
assert json.loads(json.dumps(s)) == s2. Инвариант. Что-то, что всегда истинно про результат: длина, сумма, упорядоченность, «баланс не ушёл в минус», «id уникальны».
3. Идемпотентность. f(f(x)) == f(x): нормализация, slugify, trim, дедупликация, применение миграции дважды.
@given(st.text())
def test_slugify_idempotent(s):
assert slugify(slugify(s)) == slugify(s)4. Оракул / две реализации. Сравнить быструю реализацию с медленной-но-очевидной (или со старой версией при рефакторинге): результаты должны совпадать на любом входе.
5. Метаморфические отношения. Когда «правильный ответ» неизвестен, но известно, как он должен меняться: sort(reverse(xs)) == sort(xs); добавление товара в корзину увеличивает итог ровно на цену товара.
6. «Никогда не падает». Самое дешёвое свойство для старта: на любом валидном входе функция не кидает необработанное исключение. Часто ловит первые баги ещё до того, как вы сформулировали что-то умнее.
Реальный баг за минуту
Допустим, мы написали «наивный» CSV-сериализатор:
def to_csv_row(fields: list[str]) -> str:
return ",".join(fields)
def from_csv_row(line: str) -> list[str]:
return line.split(",")Round-trip-свойство:
@given(st.lists(st.text()))
def test_csv_roundtrip(fields):
assert from_csv_row(to_csv_row(fields)) == fieldsHypothesis почти мгновенно находит и ужимает контрпример:
Falsifying example: test_csv_roundtrip(fields=[','])Поле, внутри которого есть запятая, ломает round-trip: [','] → "," → ['', '']. Классический баг CSV-экранирования, который на «нормальных» примерах (['a','b']) никогда бы не вылез. Вы его не придумывали — генератор придумал за вас. Это и есть ценность.
Stateful / model-based testing
Высшая лига PBT: тестировать не функцию, а последовательность операций над системой (очередь, кэш, БД, API). Вы описываете возможные действия и модель (упрощённый эталон), а фреймворк генерирует случайные сценарии и сверяет систему с моделью после каждого шага.
from hypothesis.stateful import RuleBasedStateMachine, rule, invariant
class CacheModel(RuleBasedStateMachine):
def __init__(self):
super().__init__()
self.real = LruCache(capacity=3)
self.model = {}
@rule(k=st.integers(), v=st.integers())
def put(self, k, v):
self.real.put(k, v)
self.model[k] = v
@invariant()
def size_within_capacity(self):
assert len(self.real) <= 3Так находят баги вытеснения, гонок состояний, рассинхрона — то, что обычным тестом ловится только случайно. Именно таким подходом Джон Хьюз с QuickCheck находил баги в распределённых БД и автомобильном софте — см. оригинальную статью QuickCheck (Claessen & Hughes, 2000), с которой всё началось.
Инструменты по языкам
Python — Hypothesis (де-факто стандарт, отличный shrinking, stateful из коробки).
JS/TS — fast-check.
JVM (Java/Kotlin) — jqwik, QuickTheories.
.NET — FsCheck.
Go — rapid, gopter.
Rust — proptest, quickcheck.
Haskell/Erlang — QuickCheck, PropEr (родина подхода).
Подводные камни — честно
Сформулировать свойство сложнее, чем кейс. Это главный барьер. Начинайте с «не падает» и round-trip, дальше войдёте во вкус.
Генератор должен покрывать реальное пространство. Если ограничить
st.text()только ASCII — не найдёте багов с Unicode. И наоборот: слишком широкий генератор даёт «нереальные» падения.Флак при скрытой недетерминированности. Свойство, зависящее от времени/глобального состояния/реального рандома, будет мигать. Фиксируйте время и seed.
Воспроизводимость. Hypothesis хранит базу упавших примеров и при следующем прогоне проверяет их первыми — коммитьте её в CI, иначе «поймал баг локально, в CI зелено».
Скорость. PBT-тест в сотни раз тяжелее одного юнита. Держите его в отдельном прогоне/наборе, а не в самом горячем pre-commit.
Это не замена примерам. Конкретный регресс-кейс на найденный баг по-прежнему полезен (быстрый, читаемый). PBT и примеры дополняют друг друга.
Как внедрить за один спринт
Возьмите одну «чистую» функцию с понятным контрактом: парсер, сериализатор, нормализатор, расчёт.
Напишите два свойства: «не падает» + round-trip (или инвариант).
Прогоните — почти наверняка что-то найдётся; ужатый контрпример превратите в обычный регресс-тест.
Закоммитьте базу примеров Hypothesis в репозиторий, добавьте PBT-набор в CI отдельным шагом.
Дальше добавляйте свойства на оракул (при рефакторинге — старая vs новая реализация) и, когда созреете, stateful-модель на ключевую структуру данных.
Вывод. Property-based тестирование закрывает слепое пятно тестов-на-примерах: оно systematically бьёт по входам, до которых вы не додумались, и при падении даёт минимальный, читаемый контрпример. Стоит начать с одной функции и пары свойств «не падает + round-trip» — и вы удивитесь, что найдёте уже в первый день.
Пишу про практику QA каждый день в Telegram-канале «QA — Quality Assurance»: t.me/qa10100011000001. Если зашло — забегайте.