Почему важно писать поддерживаемые тесты
Когда речь заходит о том, как писать тесты, многие новички думают: "Лишь бы покрыть код". Но на практике всё не так просто. Тест, написанный ради галочки, через пару месяцев становится головной болью. Он ломается от малейшего изменения в коде, его страшно трогать, потому что непонятно, зачем он вообще нужен. В результате — вместо ускорения разработки, тесты тормозят процесс. Если вы хотите писать тесты для программирования, которые реально помогают, а не мешают, нужно сразу закладывать в них поддерживаемость.
Хороший тест — это не тот, который просто проходит. Это тот, который легко понять, легко изменить и который продолжает быть полезным даже спустя месяцы. Он как хороший документ — не только для компьютера, но и для других разработчиков. Особенно когда проект растёт, и над ним работают десятки людей.
Частые ошибки новичков при написании тестов
Начнём с того, что большинство начинающих разработчиков сталкиваются с одними и теми же проблемами. И если вы уже писали тесты для разработки, то, скорее всего, узнаете себя.
1. Тесты, завязанные на детали реализации
Одна из самых распространённых ошибок — тестировать не поведение, а внутренности. Например, если функция сортировки вызывает метод `.sort()`, и вы это проверяете — вы привязываетесь к реализации. А стоит поменять алгоритм, и тесты падают, хотя программа работает корректно.
Пример:
```python
плохой пример
def test_sort_calls_builtin_sort(monkeypatch):
called = False
def fake_sort(*args, **kwargs):
nonlocal called
called = True
monkeypatch.setattr(list, "sort", fake_sort)
sort_function([3, 1, 2])
assert called
```
Так делать не стоит. Гораздо лучше проверять результат функции, а не то, как она его добивается.
2. Слишком много моков и заглушек
Когда в каждом тесте мокаются десятки зависимостей, это тревожный звоночек. Такой тест становится хрупким и его сложно понять. Часто моки используются не потому, что нужны, а потому что архитектура кода не позволяет иначе. И тут важно понимать: если вы не можете написать тест без кучи моков — возможно, проблема не в тесте, а в коде.
3. Отсутствие изоляции
Новички часто пишут тесты, которые зависят от состояния базы или файловой системы. В результате один тест может сломать другой. Чтобы писать легко поддерживаемые тесты, нужно помнить про изоляцию — каждый тест должен быть независимым. Это особенно важно при параллельном запуске тестов, где порядок выполнения не гарантирован.
Принципы написания легко поддерживаемых тестов
Теперь давайте разберёмся, как писать такие тесты, которые будут работать стабильно, легко читаться и не вызывать боли при поддержке.
Тесты должны быть простыми и читаемыми
Тест — это не место для гениальных решений. Если вы используете хитроумные конструкции, которые сложно понять с первого взгляда — вы создаёте себе проблемы в будущем. Используйте говорящие имена, разбивайте тесты на понятные шаги: подготовка данных, вызов функции, проверка результата.
Пример:
```python
def test_calculate_total_discount_applies():
order = Order(items=[Item(price=100), Item(price=50)])
discount = Discount(percent=10)
total = calculate_total(order, discount)
assert total == 135 # (100 + 50) * 0.9
```
Такой тест можно понять без комментариев. Он короткий, изолированный и проверяет поведение, а не реализацию.
Один тест — одна проверка
Старайтесь, чтобы тест проверял только один аспект поведения. Это облегчает отладку: если тест упал, сразу понятно, что именно пошло не так. Когда в тесте 5-6 assert-ов — уследить за всем становится сложно.
Избегайте дублирования
Когда вы копируете один и тот же код в десятки тестов, это затрудняет изменение логики. Попробуйте вытаскивать общие части в фикстуры или хелперы. Главное — не переусердствуйте: тесты должны оставаться читаемыми.
Почему тесты должны быть быстрыми
Медленные тесты — зло. Если тестовая прогонка занимает 20 минут, никто не будет её запускать перед коммитом. В результате баги попадают в продакшн. Стремитесь к тому, чтобы весь набор тестов запускался за 1-2 минуты. Это возможно, если избегать интеграционных тестов там, где можно обойтись юнит-тестами, и не обращаться к реальным базам данных без необходимости.
Факт:
По данным GitHub, тестовые пайплайны, которые выполняются более 5 минут, в 78% случаев реже запускаются локально. Это напрямую влияет на качество кода и количество багов.
Когда стоит писать тест — до или после кода?
Здесь всё зависит от подхода. Если вы работаете по TDD (разработка через тестирование), то тест пишется первым. Это помогает сфокусироваться на интерфейсе и поведении функции. Если же вы работаете в более классическом стиле, не страшно писать тесты после. Главное — чтобы они были. И чтобы они были поддерживаемыми.
В моей практике тест, написанный после кода, часто оказывается менее читаемым. Почему? Потому что вы уже знаете, "как всё работает", и бессознательно привязываетесь к реализации. Поэтому, даже если вы не фанат TDD, попробуйте хотя бы формулировать поведение до написания кода — это уже помогает писать лучше.
Что делать со "старыми" тестами
Проекты живут долго. Через год разработчик, писавший тест, может уйти из команды, а в коде всё изменится. Но тесты остаются. Поддерживаемые тесты — это те, которые можно легко адаптировать под новые требования. Если вы видите, что тест стал бесполезным или постоянно "красным" — лучше его удалить или переписать. Хуже теста нет только тест, которому никто не доверяет.
Вывод
Чтобы писать тесты для программирования, которые действительно помогают, нужно думать не о том, как покрыть код, а о том, как облегчить себе и команде жизнь в будущем. Легко поддерживаемые тесты — это те, которые читаются, как история, изолированы, быстры и не завязаны на детали реализации. Ошибки новичков — это нормально. Главное — учиться на них и постепенно вырабатывать тестовую культуру, которая делает разработку надёжной, а не хаотичной.
