На прошлой неделе я вынюхал, что 10-ть “избранных” программистов отправят на курсы TDD (Test Driven Development), и решил пробраться в эту десятку. К большому сожалению, я узнал немного поздновато – за пару дней, но все же решил написать емейл начальнику и посмотреть что будет. Емейл был краткий: “Не могли бы вы меня как нить засунуть на курсы TDD?” Ответ пришел день спустя – засунули!
Компания, которая проводит курсы, называется Pillar и располагается в городе Анн Арбор, что в 40 минутах езды от дома – в принципе не так плохо, но все же далековато. Сегодня был первый из двух дней курса. Прошло все отлично, конечно была пара маленьких технических заморочек, но без них ни куда! В инструкции было написано все что нужно и скажу сразу, найти парковку в Анн Арборе в рабочие дни не так уж и просто. Но компания все показала и рассказала, а потом ещё дала кредитную карту на $25 – чтобы мы “без пыли и шуму” оплатили парковку прямо рядом со зданием. Смеха ради отмечу, что парковка на рабочий день была $10. Так же из разряда других приятных мелочей, у компании Pillar есть свой шеф повар, который приготовил нам всем обед! Это не прошло мимо нашего отряда программистов. Мы сразу решили, что у нас такое тоже должно быть! И не подумайте – это вам не какие-то детские забавы, тут мы боремся с “автобусным” фактором.
От приятного к делу! Пока что курсы мне нравятся, так как меня всегда интересовала TDD. Я понимаю что и как, но всегда хотелось окунуться в это и я окунулся. Скажу, что идея однозначно интересная и даже стоящая. Однако, меня преследует какая-то странная паранойя, которую пока что не могу сформулировать! Но процесс написания программы, который начинается с теста, потом пишется код, потом пишется ещё тест и потом ещё код, а потом рефакторинг тестов и кода и так далее, пока код ни закончен – чем-то мне напомнил брутфорс (bruteforce)! Пока мы тренировались (code kata), я решил прикольнуться над своим партнером и писать тупой код – типа чтобы он тупо проходил тесты и все. И тут можно легко заключить следующее – TDD не избавляет от быдло-кода или плохого программирования. Он избавляет от других недочетов, таких как:
– четкое представление задачи (без этого будет сложно)
– большая модулярность
– лучшее покрытие тестами
– легкий рефакторинг кода в любой момент
– документация
В итоге, я думаю, что TDD довольно хороший подход и использовать его нужно. Однако, что-то мне ещё не дает покоя и когда я додумаю, то, возможно, изменю свое мнение. Чирз!
Да, TDD – интересный подход, сносит крышу, когда пытаешься писать тесты для кода, дизайн которого ещё пока думается по-старому. Мне, например, удалось вынести факт того, что методы делегата вызываются на главном потоке, в отдельный класс => в тестах я использую синхронные вызовы => тесты стали проще, понятнее, и быстрее (я почти избавился от асинхронных тестов) (DI рулит)! Наверное, это выглядит странно для тех, кто всегда привык писать `dispatch_async(dispatch_get_main_queue(), ^{ foo(); });`
Надо было выложить фотки кода, TDD, результаты тестов, а то непонятно что показывают :)
> Он избавляет от других недочетов, таких как:
Мне кажется, у тебя предложение инвертировано. По идее, должно быть “TDD генерирует такие плюшки:
– чёткое представление задачи (без этого будет сложно, очень);
– большая модулярность;
– …”
> TDD не избавляет от быдло-кода или плохого программирования
Да, и 100% test code coverage, к сожалению, не избавляет от багов. Для этого нужно сильно больше тестов и воображения, что может пойти не так.
Женя, напиши, когда курс закончится и ты попробуешь TDD на каком-то проекте. И в подкасте расскажи. “Чирз!”
Постараюсь еще написать и поговорить в подкасте. Однако у меня TDD уровень еще малый, нужно тренироваться. Я постараюсь.
Спасибо!
Добавил фоток! Наслаждайтесь.