В ходе недавнего интервью для JUG.RU я отвечал на один из вопросов в примерно такой формулировке: “TDD – это замечательный подход и все об этом говорят, но на практике оказывается, что тестов пишется мало и далеко не все следуют данному подходу. Дело тут в лени разработчиков?”. Полная версия интервью еще готовится к публикации, но я для затравки решил опубликовать ответ на этот вопрос.

Тут дело не в лени разработчика. Тут дело в двух причинах, на мой взгляд.

Первая – это то, что люди не умеют этого делать. Для того, чтобы разрабатывать по TDD, необходима подготовка. И мало этого, необходимо понимание инструментария, как им пользоваться и какое он дает преимущество. Человек, который проходит курсы, или сам изучает TDD, или садится работать с кем-то грамотным, кто уже работает по TDD, видит столько преимуществ в работе, что после этого ему становится понятно, что глупо так не делать.

А вторая причина – это то, что многие из разработчиков, особенно с завышенной самооценкой, «включают режим архитектора». Это когда человек посмотрел на задачку одним глазком и говорит: «Окей, все, я вижу. Вот здесь у меня будет фабрика, здесь будет такой-то паттерн, здесь – такой-то». И он сразу эти мысли выплескивает в код. Потом наступает момент, когда надо интегрировать всё то, что он «напроектировал», с остальным кодом. И становится ясно, что оно не интегрируется. Или же кто-то смотрит код на code review, и становится видно, что все методы гигантские, ничего не понятно, пятой вложенности if-ы. Наверняка все видели примеры, когда «Hello, world!» при помощи дизайн-паттернов можно изобразить так, что не разберешься, что перед тобой «Hello, world!».

Когда ты работаешь по TDD, то ты написал тест, и теперь твоя задача просто в том, чтобы он заработал. Твоя задача не сделать суперклассный дизайн. Задача сделать суперклассный дизайн возникает уже после того, как код заработал. Ты потом смотришь на него и говоришь: «Вот я простое решение написал. А можно его как-то сделать красивее? Можно сделать его как-то более элегантным? Или reusable?» И если нет — ну окей. Оно работает и работает, поехали дальше. То есть вот причины: «режим архитектора» и неумение писать тесты, работать с правильным инструментарием.

Причем, если ты работаешь по TDD, то перед тобой не стоит задача писать тестируемый код, потому что у тебя нету шансов написать его нетестируемым. Если ты работаешь по TDD, то происходит так: пишешь-пишешь ты тест, наконец смотришь: «О, вот красивый API получился! Именно так и должно выглядеть, так оно и надо!» И сгенерировал быстренько весь API. Потому что благо, если мы говорим про Java-разработку, очень много всего генерируется с помощью IDE из теста и не надо писать руками. В итоге тот человек, который работает по TDD, работает чуть быстрее за счет этого фактора. Он не пишет руками ни одной сигнатуры метода, ни одного конструктора, ни одного поля. Это все генерируется. Причем мегабыстро. Все, что пишет человек, который работает по TDD – это реализации методов. IDE берет на себя создание классов, конструкторов, геттеры, сеттеры, декларации методов, очень сильно в этом помогает и экономит огромное количество времени.

В заключение, стоит упомянуть еще одну проблему с использованием TDD: TDD – это подход к разработке, который требует достаточно высокого уровня навыков дизайна кода и написания тестов. Если у вас их нет, то TDD их магически в вас не воспитает и не научит вас главному феерическому принципу любого программиста: “пиши только хороший код, а плохой не пиши вовсе”. Только тренировки могут помочь в этом вопросе, а это, в свою очередь, требует дисциплины. С дисциплиной у разработчиков, как известно, не все всегда хорошо. Вот и делаем как получается…