TDD, покрытие и тестовая пирамида

TDD: Red — Green — Refactor

Разработка через тестирование (Test-Driven Development) — сначала тест, потом код:

1. 🔴 Red — пишем тест для следующего маленького шага поведения. Он падает (кода ещё нет).
2. 🟢 Green — пишем минимальный код, чтобы тест прошёл. Даже «глупый».
3. 🔵 Refactor — улучшаем код и тесты, сохраняя зелёный цвет.
4. Повторяем.

Живой пример: калькулятор строк

Задача: add("1,2,3") возвращает сумму чисел в строке.

# Шаг 1. Red: пустая строка → 0
def test_empty():
    assert add("") == 0

# Шаг 1. Green: минимальный код
def add(numbers):
    return 0

test_empty(); print("шаг 1 ✓")

# Шаг 2. Red: одно число
def test_single():
    assert add("5") == 5

# Шаг 2. Green
def add(numbers):
    if not numbers:
        return 0
    return int(numbers)

test_empty(); test_single(); print("шаг 2 ✓")

# Шаг 3. Red: несколько чисел, в том числе с переносами строк
def test_many():
    assert add("1,2,3") == 6
    assert add("1\n2,3") == 6

# Шаг 3. Green + Refactor: обобщаем
import re

def add(numbers: str) -> int:
    if not numbers:
        return 0
    return sum(int(n) for n in re.split(r"[,\n]", numbers))

# Шаг 4. Red: отрицательные числа запрещены
def test_negative():
    try:
        add("1,-2,-3")
    except ValueError as e:
        assert "-2, -3" in str(e)
    else:
        raise AssertionError("ожидали ValueError")

# Шаг 4. Green
def add(numbers: str) -> int:
    if not numbers:
        return 0
    values = [int(n) for n in re.split(r"[,\n]", numbers)]
    negatives = [str(v) for v in values if v < 0]
    if negatives:
        raise ValueError(f"отрицательные числа запрещены: {', '.join(negatives)}")
    return sum(values)

for test in (test_empty, test_single, test_many, test_negative):
    test()
print("все тесты зелёные ✓")

Польза TDD: код сразу тестируемый, тесты не забываются, дизайн получается проще (пишем только нужное), и есть «страховочная сетка» для рефакторинга. На практике многие пишут тесты сразу после кода — главное, чтобы они были.

Тестовая пирамида

Антипаттерн — «рожок мороженого»: много ручных и E2E-тестов, мало модульных. Такие тесты медленные и ломаются от любой мелочи.

Покрытие кода

coverage.py (или плагин pytest-cov) показывает, какие строки выполнялись во время тестов:

pytest --cov=shop --cov-report=term-missing --cov-branch

Name                 Stmts   Miss Branch BrPart  Cover   Missing
----------------------------------------------------------------
shop/pricing.py         24      2     10      1    91%   41-42
shop/orders.py          58      0     18      0   100%
----------------------------------------------------------------
TOTAL                   82      2     28      1    96%

• Покрытие строк — выполнялась ли строка.
• Покрытие ветвей (--cov-branch) — прошли ли обе ветки каждого if. Это строже.

Почему 100% — не гарантия

def average(values):
    return sum(values) / len(values)

def test_average():
    assert average([2, 4]) == 3          # покрытие 100%...

test_average()
print("покрытие 100%, тест зелёный")
try:
    average([])                          # ...а ошибка на пустом списке осталась
except ZeroDivisionError as e:
    print("ZeroDivisionError:", e)

Покрытие показывает, что не проверено (полезно!), но не доказывает, что проверено хорошо. Разумная цель — 80–90% с осмысленными тестами и обязательное покрытие нового кода. Порог задают в CI: --cov-fail-under=85.

Другие техники

• Тестирование свойств (property-based, библиотека Hypothesis): описываете свойства («сортировка сохраняет элементы и упорядочивает»), а библиотека генерирует сотни входов и находит минимальный контрпример.

from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_sort_properties(xs):
    result = my_sort(xs)
    assert len(result) == len(xs)
    assert all(a <= b for a, b in zip(result, result[1:]))

• Мутационное тестирование (mutmut): инструмент вносит мелкие ошибки в код (< → <=) и проверяет, упадут ли тесты. Выживший мутант — дыра в тестах.
• Snapshot-тесты: сравнение большого вывода (JSON, HTML) с сохранённым эталоном.
• Контрактные тесты между сервисами (Pact).

Тесты в CI

# .github/workflows/tests.yml
name: tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv sync --dev
      - run: uv run ruff check .
      - run: uv run mypy src
      - run: uv run pytest --cov=src --cov-fail-under=85

Pull request не сливают, пока CI не зелёный.

Flaky-тесты

«Мигающий» тест иногда падает без изменений кода. Частые причины и решения:

Flaky-тест чинят сразу: иначе команда привыкает игнорировать красный CI.

Итог

• TDD: Red → Green → Refactor маленькими шагами.
• Пирамида: много модульных, меньше интеграционных, немного E2E.
• Покрытие (pytest --cov --cov-branch) показывает непроверенный код, но 100% не гарантирует отсутствия ошибок.
• Hypothesis, мутационное тестирование, тесты в CI; flaky-тесты чинят сразу.