Коротко — почему работает
- Property‑based testing (PBT) генерирует много разнообразных входов (включая пустые, с дубликатами, границы и т.п.), автоматически ищет контрпримеры и умеет «сжимать» их до минимального случая. Это находит ошибки, которые не уловить набором явных примеров, потому что разработчик может не предусмотреть взаимодействие крайних условий или редкие комбинации значений.
Пример (pytest + hypothesis). Проверяем реализацию сортировки `my_sort` через свойства, а не через один пример:
from hypothesis import given, strategies as st
from collections import Counter
@given(st.lists(st.integers()))
def test_my_sort_properties(xs):
ys = my_sort(xs)
# 1) результат отсортирован
assert ys == sorted(ys)
# 2) результат — та же мультимножество (не потеря и не дублирование элементов)
assert Counter(xs) == Counter(ys)
# 3) идемпотентность: сортировка дважды = один раз
assert my_sort(ys) == ys
Какие классы багов это поймает
- Потеря элементов (off‑by‑one, срезы типа `xs[:-1]`) — поймает проверка мультимножества (Counter). Типичный минимальный контрпример: `xs = [1]` или `xs = [1,2]`.
- Удаление дубликатов (когда реализация делает `sorted(set(xs))`) — поймает мультимножество; минимальный контрпример: `xs = [1,1]`.
- Некорректный компаратор/условие сортировки — поймает несоответствие отсортированности; контрпример может быть что-то вроде `xs = [2,1]`.
- Нестабильность/рандомизация (функция возвращает разные результаты) — поймает идемпотентность: второй вызов не равен первому.
- Пограничные случаи: пустой список, один элемент, длинные списки, повторяющиеся элементы, отрицательные/очень большие числа — Hypothesis генерирует такие случаи и минимизирует их при провале.
Почему это лучше простых примеров
- Простейшие unit‑тесты обычно покрывают «обычные» случаи, но мало вероятно, что угадают нужные комбинации граничных значений или редкие последовательности; PBT систематически ищет и сжимает ошибки до простейшего контрпримера, который легко проанализировать.