В чем разница: "тесты до" или "после" кода?

Как-нибудь потом (или никогда) расскажу, как проходил тренинг с точки зрения тренерской. Сейчас же хочу об TDD. мысли накопились, хочу слить их.

Сам по себе плохо работает, его поддерживают тяжеловесные инж. штуки: рефкторинг, test list, OOP, unit testing, и только если все в комплексе, тогда получится. А еще голову надо сломать об стену, пока не станешь на рельсы - причем ломать надо конкретно, по очень привычным направлениям: не дебажь, но откати; не думай об архитектуре сильно - рефакторинг сам позаботится о ней; пиши код по чуть-чуть, после безжалостно рефакторь его; не реализуй мысль, не обождавшую в тестлисте; не верь тому, что пишешь; страшно - пиши тесты; не предполагай - проверяй тестами. И это только из числа первых шишек.

Понятно, почему в XP коуч в команде личный есть. Обычно, с ТДД потому и спрыгивают, что внедряют его ребята не совсем опытные, в проекте не совсем подготовленном. И тут двухдневным тренингом не отделаться - необходимы комплексные меры, либо очень подготовленный (рефакторинг, ООП, юнит тестирование) проект. А еще, что ставит почти финальную точку - то, что учим ТДД с нуля на простых вещах, а на проекте тем временем ждет хороший такой легаси проект, к которому прикрутить ТДД еще надо ой как постараться - тут тебе и high coupling и low cohesion. Тут-то и возникает первое заблуждение - TDD для проектов "с нуля". Пускай так, но когда наступает этот первый проект - его тесты будут ужасными, потому как все ждали нового проекта, чтобы применить в нем ТДД, но все это время ни на йоту не прокачались в unit тестировании.

Тесты-якоря - от которых каждый раз спотыкаясь, с матом, хочется избавиться случаются от отсутствия опыта. ТДД на новом проекте так же не заведется. Опять же нет коуча, того парня или той девушки, которая 100 раз подавляли в себе желание спрыгнуть с ТДД, потому как: "сложно написать тест", "это отнимает много времени", "заказчик никогда не пойдет на это" и так далее...

Очень сильно запомнился вопрос "нафига ТДД", но его можно нагуглить, а я хочу немного приоткрыть вопрос "в чем разница - писать тесты до или после кода?". А разница огромна и вот почему:

- Если тесты писать до, тогда система получится какая-то более модульная, что-ли. Потому как моно сказать (один раз), что код пишется немножечко для тестов. А какой код легче протестить? Оформленный в отдельный модуль. Вот тебе и слабая связность. А если писать тесты после - тогда и вопрос законный "а как тестировать приватные методы?", "как сделать чтобы тесты небыли такими хрупкими" - выделяйте зависимости и пишите юнит тесты, но ломает, потому как дополнительная работа, а код уже написан. Вот и получается что...

- Сode coverage тестами (написанными после кода) низок. А еще полагаться на тулзу, которая говорит что на проекте 80% code coverage можно, но я бы не стал сильно. Потому как можно написать такой один тест, который походит по основным флоу и соберет X%, но это вовсе не значит что функциональные требования покрыты - просто процессор побывал в некотором числе строк. Вот если закомментировать любую строку в коде проекте и при этом соответствующий функциональности тест свалится всегда - вот тут 100% покрытие. С ТДД кода пишется настолько мало, насколько это нужно для зеленой полосы. Но если какая-то строчка проскочила тут, то на этапе рефакторинга она должна быть удалена, потому как удаляется весь код, который не приводит к поломке тестов. Дабл чек. Покрытие максимальное и становится меньше 100% только за счет того, что где-то написали больше чем надо было для теста, а на рефакторинге схалтурили :) Но это тут каждый сам себе доктор. Идем дальше, о рефакторинге...

- Рефакторинг всегда по чуть чуть приводит к той самой хорошей архитектуре, о которой изначально не стоило думать. Умеешь делать рефакторинг, понимаешь принципы ООП - будет тебе счастье. Тут ТДД тем лишь ценный, что предоставляет для рефакторинга зеленую полосу так часто, как это возможно - каждые 10-15 минут (при условии, что с ТДД у нас проблем нет). И рефактори себе на здоровье: поломал - откати, есть зеленая полоса и стало чище - коммить! Когда пишем код а потом покрываем его тестами - рефакторинг не очень то и хочется делать - поломаешь ведь. А с ТДД рефакторинг в кайф. Представь, что тебе придётся собирать кубик рубика (что само по себе задача не простая, даже если знать как) без того самого основания на котором все держится - это возможно, но чертовски сложно, постоянно все ломается. Так и рефакторинг без тестов. Тесты и есть то самое основание кода. Верти себе грани на здоровье. Рефакторинг в кайф - это еще одно преимущество, которое мне дает ТДД в процессе разработки.

- Любой человек ошибается часто. Глупые ошибки он делает приблизительно раз в 5 минут. Это я по себе и коллегам, с кем удалось в паре поработать, сужу. Банальная очепятка. Думаю одно - пишу другое. Нет тестов, нет фидбека о том, что ты ошибся. Поработал 2 часа? Вот тебе и 20 ошибок, которые надобно отладить. А для этого кто нужен? Дебаггер. Ничего против не имею, использую регулярно, но с ТДД я его использую, когда мне хочется (допустим, любопытно что-то), а не когда я вынужден это делать потому как система не работает и я понятия не имею в чем дело - а это самый дорогой процесс. С ТДД его можно максимально сократить. Поломал что-то? 5 минут всего прошло от коммита? Ривертни и попробуй еще раз. Снова ошибся - сделай перерыв.

- Система развивается постепенно, уверенно и предсказуемо. Тут нет места сложным неопределенностям. Поработав два часа я могу с большой уверенностью ответить, когда точно закончу потому, как на руках есть test list в котором описано какие тесты еще остались и спустя 2 часа работы он максимально подробный (и обычно идет на убыль для небольшой фичи). Предсказуемо, значит без стресса. Нет стресса - меньше глупых ошибок, здоровее организм. Но если хочется больше экшена, неопределённости, нравится двухчасовой дебаг с восклицанием "я нашел ее!" (а ошибка-то была банальной очепяткой, которую ТДД просто не допустил бы), тогда лучше по классике.

Еще еще преимущества, которые замечаешь только, если в какой-то момент начинать их искать. Тут как с грибами - их вроде как нет, но опытный грибник.... И в этом, наверное, основная роль коуча - искать ответы на вопрос "как выжать из этого по максимуму?" и помочь другим увлечься этим процессом. Я научился работать в таком ключе и очень рад тому, что еще не перестаю открывать новое.