TDD и опытные разработчики

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

На это у меня есть обкатанное решение. Достаточно просто обсудить с разработчиком самые обычные активности, которые он выполняет в процессе написания кода.

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

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

Проходит стадия причесывания кода и после промежуточных результатов хорошие разработчики делают интеграцию и тестируют как все работает вместе - нажимают на кнопочки в UI (после редеплоймента, логина, поиска новой формочки, ввода тестовых данных), делают вызовы веб-сервисов (например, пишет запрос руками через Fiddler), во время тестов запускаются процессы, которые занимают значительное время - и все это не так-то и быстро, а вообще обычно нудно и медленно и как-то подмывает побыстрее с этим закончить, а баги-то этого только и ждут.

Опытные разработчики также не отрицают тот факт, что первый тест обычно не работает и тестирование приходится повторять вновь и вновь. Вновь и вновь.

Так вот, вывод прост - хорошие разработчики уже тратят время на тестирование, причем значительное количество своего времени. Это факт.

Юнит-тестирование - это реструктуризация этого времени и более эффективное его использование. Вы делаете то же самое тестирование, занимающее столько же времени, сколько и раньше, однако результат фиксируется и попадает в репозиторий, и может быть снова и снова использован вами или вашими коллегами для повторного тестирования.

Так что пишите юнит-тесты и вам не придется сожалеть о непротестированном коде.