Тамуна прочитала книгу про Test-Driven Development и загорелась идеей.
Концепция выглядела логично: сначала тест, потом код, потом рефакторинг. На курсах она успешно применяла TDD для учебных задачек. Теперь предстояло проверить метод на боевом проекте — системе корзины для онлайн-магазина.
Первая неделя: столкновение с реальностью
Тамуна начала с функции добавления товара в корзину.
По TDD нужно сначала написать падающий тест. Но как написать тест для функции, которой еще не существует? Какие параметры она принимает? Какой формат данных возвращает?
| Этап | Теория из книги | Реальность Тамуны |
| Написание теста | 5 минут | 40 минут размышлений |
| Реализация кода | 10 минут | 15 минут |
| Рефакторинг | 5 минут | Не требовался |
| Переписывание теста | Не упоминается | 25 минут — 3 раза |
Тамуна переписывала тесты постоянно. Задумала одну структуру данных, а в процессе реализации поняла — нужна другая. Приходилось менять и тесты, и код.
Сравнение с традиционным подходом
На второй неделе техлид предложил эксперимент.
Одну функцию Тамуна делает через TDD, другую аналогичной сложности — традиционно, тесты после кода. Вот результаты:
| Параметр | TDD (добавление в избранное) | Традиционный (удаление из корзины) |
| Время разработки | 3.5 часа | 2 часа |
| Количество багов | 1 (логическая ошибка) | 3 (две логические, одна граничный случай) |
| Время отладки | 20 минут | 1.5 часа |
| Качество кода | Чистый, модульный | Работает, но запутанный |
Традиционный подход оказался быстрее на этапе написания. Но TDD сэкономил время на поиске и исправлении ошибок.
Месяц спустя: изменения требований
Заказчик попросил добавить поддержку промокодов в корзину.
Тамуна вспомнила, как писала тесты для расчета итоговой суммы. Она четко описала в тестах все случаи: пустая корзина, один товар, несколько товаров, товары с разными налогами.
Добавление промокодов потребовало изменить логику расчета. Благодаря существующим тестам Тамуна сразу увидела, что сломалось. Исправление заняло час вместо потенциального дня отладки.
Что действительно помогло
Тамуна выделила три реальных преимущества TDD на своем опыте:
- Тесты заставляют продумать интерфейс функции до реализации
- Код получается более модульным — иначе его сложно тестировать
- Изменения в коде безопаснее — тесты сразу показывают поломки
Но были и сложности. TDD замедлял работу, когда Тамуна не понимала задачу полностью. Приходилось делать spike-решение — быстрый прототип без тестов, чтобы разобраться в проблеме.
Теперь Тамуна использует TDD выборочно: для сложной бизнес-логики обязательно, для простых CRUD-операций — после кода
Спустя два месяца ее модуль корзины работает без критических багов. Коллеги отмечают, что код Тамуны легко читать и менять.