Я уже много лет применяю разработку через тестирование (TDD) в различных проектах. Я нередко являюсь свидетелем того, как разработчики изначально используют TDD, но позже отказываются от него в своей повседневной работе. Это явление вызывает важнейший вопрос: почему это происходит? Это потому, что TDD работает только в простых игрушечных проектах или в чем-то тривиальном, например, в настройке онлайн-курсов? Абсолютно нет, и я здесь, чтобы объяснить почему.

Задача состоит не просто в том, чтобы придерживаться классического цикла рефакторинга «красный-зеленый», но и в освоении предшествующего ему шага — критического процесса, называемого «постановка задач».

Распаковка задач

Постановка задач может стать частью вашего ежедневного рабочего процесса, даже если вы этого не осознаете. Это системный подход к решению проблем, который предполагает разбиение требования на управляемые, последовательные задачи. В идеале эти задачи должны быть выполнены за время от нескольких минут до часа.

Разработка через тестирование (TDD) сродни искусству рисования. Вы начинаете с эскиза или черновика, обрисовывая карандашом основные формы и линии, что очень похоже на создание первоначальной структуры вашего кода. Первоначально видение может быть расплывчатым, просто идеей или концепцией в вашем уме. Но по мере того, как вы рисуете или пишете тесты и код, изображение начинает обретать форму. Добавляется больше элементов, появляются детали и вносятся корректировки, что позволяет постоянно совершенствовать. С каждым слоем или итерацией появляется ясность, но точный окончательный вид остается загадкой до самых последних этапов. Подобно тому, как художник создает шедевр путем постепенного развития, TDD создает надежное и элегантное программное обеспечение.

Как ставить задачи

Допустим, нам нужно создать приложение, которое позволит клиентам заказывать пиццу онлайн. Можно рассмотреть два различных возможных подхода к постановке задач: снизу вверх или сверху вниз.

Стиль «снизу вверх»