Чтож, пришло время подвести итоги моего 2ухмесячного тура по TDD. Краткие выводы - я не понимаю, как вообще писал код до этого😅

Основной мой тезис, что любая разработка УЖЕ ВЕДЕТСЯ ПО TDD, и мы этого не осознаем. Просто это Manual TDD. Как мы пишем код для решения задачи Х?

1) Изучаем задачу
2) Формируем требования к коду, который будет ее закрывать
3) Пишем код
4) Проверяем, что сформированные в П.2 требования выполняются (мануально)
5) Пишем тесты???

Но, если у нас уже есть список требований, то почему бы просто не зафиксировать их тестом!? Идея на поверхности, но она полностью меняет ощущения от самого процесса.

К тому же, я сам частенько переходил на TDD в сложных случаях.
Как мы фиксим багу? - пишем красный тест, делаем его зеленым, рефакторим
Как мы рефакторим старый код? - аккуратно исправляем его так, чтобы тесты не сломались
Как мы пишем сложную фичу? - пишем N тестов и пытаемся написать код, который закроет их все разом.

Если ты фиксируешь требования к новому коду через тесты, то

1) Ты гораздо лучше формируешь сами требования. Они превращаются из абстрактных хотелок в твоей голове в конкретный API с конкретными инвариантами. В итоге часто случается, что картинка API нового модуля из твоей головы, в процессе написания теста оказывается неверной - и рождается новый дизайн.

2) Тест является для тебя определенной ступенькой на пути к полной реализации (см. One Step Test), ниже которой ты не можешь провалиться. Ты как альпинист, который по мере поднятия на вершину, переносит страховочные крепления все выше и выше. Начиная с самого тривиального теста, ты докидываешь новые и новые проверки инвариантов без страха, что предыдущие отвалятся. Такое тестовое покрытие прямо в процессе дает коллосальное чувство спокойствия, позволяет держать меньше деталей в голове, и сконцентрироваться только на задаче, решаемой в эту секунду.

3) Если альпинист не может поставить страховку выше того места, где он находится, то в случае с тестами мы можем это сделать! (см Fake It). Красный тест - это цель, к которой натянута веревка - нам будет очень тяжело отклониться от нее. Наличие красного теста буквально за руку ведет нас к реализации функционала. Писать код становится в разы проще.

4) Скорость разработки также кардинально увеличивается. Запустить тест - это гораздо быстрее, чем мануально проверить выполнение логики. Если ты не пишешь все идеально с первой попытки, то такие проверки-перепроверки придется совершить N раз. Сложная логика также требует сложных мануальных манипуляций. Напиши тест! - он выполняется за 0.1 секунды.

Экстремальные адепты TDD даже юзают утилиты, которые сразу запускают тесты при изменении в любых файлах - https://pypi.org/project/pytest-watcher/

5) Наличие тестового покрытия на основные инварианты из коробки банально повышает качество итогового программного продукта. За него не нужно биться или "обеспечивать" - оно уже есть.

6 - бонусный пункт от меня) Написание тестов - отличный способ борьбы с прокрастинацией. Вот надо тебе съесть слона - и ты сидишь и думаешь, с какого бока к нему подступиться. Напиши тест, а лучше два (см. Триангуляция) - это уже будет маленький шажок на пути к ожидаемому результату. Или у тебя просто есть 15 минут между созвонами и ты физически не можешь воткнуть туда полноценное решение задачи - напиши тест! Это занимает 2 минуты, требует околонулевых мозговых затрат, зато приближает тебя к итоговой цели.

7 - бонусный пункт от меня) TDD идеально сочетается с AI-DD, т.к. подразумевает итеративные атомарные изменения кода, где у AI остатется мало пространства для галлюцинаций. А наличие тестов позволяет быстро отлавливать такие галлюцинации.

TDD - это не просто инструмент или конкретный подход. Это целая идеология. Ты можешь готовить ее множеством способов. Не нравится писать много юнит-тестов, т.к. фича слишком проста, чтобы тратить на это время? - увеличивай шаги, пиши высокоуровневые красные тесты (см Fake It, Obvious Implementation).

#TDD