TDD (Test‑Driven Development) в действии на pet‑проекте: пошаговый гайд

Представьте ситуацию: вы пишете новую функцию для своего пет-проекта - например, калькулятор или трекер привычек. Код работает, но вы не уверены, что он не сломается при следующем изменении. Здесь на помощь приходит TDD (методология разработки программного обеспечения, основанная на написании тестов до реализации функциональности). Это не просто набор правил, а способ мышления, который превращает хаос в предсказуемую систему. В этой статье мы разберем, как внедрить TDD в реальный проект с нуля, используя конкретный пример на Python.

Суть подхода: почему тесты идут первыми?

Тест-драйвен разработка опирается на цикл «Красный-Зеленый-Рефакторинг». Сначала вы пишете тест, который должен провалиться (красный), затем минимальный код, чтобы он прошел (зеленый), и наконец улучшаете структуру кода без изменения логики (рефакторинг). Такой подход гарантирует, что каждая строчка кода имеет четкую цель. Вы не тратите время на написание лишних функций, которые потом могут оказаться ненужными. Вместо этого вы строите архитектуру, исходя из требований, зафиксированных в тестах.

Многие разработчики боятся, что TDD замедлит работу. На практике же это экономит часы отладки. Когда баг появляется, вы сразу знаете, какой тест его поймал. Это особенно важно в пет-проектах, где нет команды QA, и вы сами отвечаете за качество продукта.

Подготовка рабочего места: инструменты и окружение

Для начала нам понадобится интерпретатор Python версии 3.10 или выше. Мы будем использовать фреймворк pytest - популярную библиотеку для автотестирования, которая отличается простотой синтаксиса и мощной системой фикстур. Установить их можно через менеджер пакетов pip:

1. Откройте терминал.
2. Выполните команду pip install pytest.
3. Создайте папку проекта, например, todo_app.
4. Внутри создайте две директории: src для исходного кода и tests для тестовых файлов.

Такая структура разделит ответственность: бизнес-логика находится в одном месте, а проверка ее работоспособности - в другом. Это упрощает навигацию по проекту и делает его масштабируемым.

Практический пример: реализуем функцию добавления задачи

Допустим, наш пет-проект - это простой список дел (Todo List). Первая функция должна позволять добавлять задачу. Согласно TDD, мы начинаем с файла tests/test_todo.py. Пишем тест, который проверяет, что после вызова функции задача сохраняется в списке:

def test_add_task():
    tasks = []
    add_task(tasks, "Купить молоко")
    assert "Купить молоко" in tasks

Запускаем тест командой pytest -v. Он падает с ошибкой NameError: name 'add_task' is not defined. Это ожидаемо - мы еще не написали саму функцию. Теперь переходим к файлу src/todo.py и пишем минимальную реализацию:

def add_task(task_list, task_name):
    task_list.append(task_name)

Снова запускаем тест. Он проходит (зеленый свет). Но код пока сырой. Что если передать пустую строку? Или число? Добавляем новый тест для проверки граничных случаев:

def test_add_empty_task_raises_error():
    tasks = []
    with pytest.raises(ValueError):
        add_task(tasks, "")

Тест снова красный. Теперь дорабатываем функцию, добавляя проверку:

def add_task(task_list, task_name):
    if not task_name or not isinstance(task_name, str):
        raise ValueError("Task must be a non-empty string")
    task_list.append(task_name)

Все тесты зеленые. Функция готова к использованию. Обратите внимание: мы не писали документацию или комментарии заранее. Логика стала очевидной из самих тестов.

Структура данных и работа с объектами

По мере роста проекта простой список задач становится неудобным. Нам нужна структура, которая хранит название, статус и дату создания. Здесь пригодится класс Task. Снова следуем циклу TDD. Сначала тестируем создание объекта:

class Task:
    def __init__(self, title, status="pending", created_at=None):
        self.title = title
        self.status = status
        self.created_at = created_at or datetime.now()

Тест проверяет, что атрибуты присваиваются корректно. Затем тестируем изменение статуса. Например, метод complete() должен менять статус на "done". Если забыть реализовать этот метод, тест мгновенно укажет на проблему. Такой подход позволяет избежать типичных ошибок, когда логика распределена по разным методам класса и теряется целостность состояния.

Типичные ошибки новичков и как их избежать

Одна из самых частых проблем - попытка написать слишком сложные тесты сразу. Новички часто пытаются покрыть все возможные сценарии в одном тесте. Лучше разбивать логику на мелкие атомарные проверки. Один тест - одна идея. Если тест назван test_user_login_and_profile_update, значит, он делает слишком много. Разбейте его на test_user_login и test_profile_update.

Другая ошибка - игнорирование рефакторинга. После того как тесты стали зелеными, разработчики часто забывают улучшить код. Но именно на этом шаге формируется чистая архитектура. Используйте принципы SOLID и удаляйте дублирование. Если два теста проверяют похожую логику, вынесите общую часть в вспомогательную функцию.

Также важно следить за зависимостями. Если ваша функция зависит от базы данных или внешнего API, используйте мок-объекты. Библиотека unittest.mock входит в стандартную библиотеку Python и позволяет изолировать юнит-тесты от внешних систем. Это ускоряет выполнение тестов и делает их независимыми от состояния среды.

Интеграция с CI/CD: автоматизация контроля качества

Пет-проект может остаться локальным, но если вы планируете делиться им с сообществом, настройте непрерывную интеграцию. Сервис GitHub Actions позволяет бесплатно запускать тесты при каждом пуше в репозиторий. Создайте файл .github/workflows/tests.yml с конфигурацией запуска pytest. Теперь каждый коммит будет проверяться автоматически. Если тесты упадут, вы получите уведомление до того, как код попадет в основную ветку. Это создает культуру качества, даже если над проектом работаете только вы.

Автоматизация также помогает отслеживать покрытие кода. Инструмент Coverage.py показывает процент протестированных строк. Стремиться к 100% не обязательно, но критические пути должны быть покрыты полностью. Низкое покрытие в модуле сигнализирует о том, что там скрыто больше всего потенциальных багов.