Размышления о TDD
20.11.2010 технологии
После прочтения «Совершенного кода» и в связи с интересом к TDD уважаемого мной программиста Жени Сергеева, естественно, не мог оставить без внимания TDD и я. Читаю, интересуюсь, присматриваюсь.
Понятно, что качество должно улучшаться, но какой ценой? Честно говоря, меня очень пугают оценки из статьи Ошибки начинающих TDD-практиков — на то, чтобы врубиться в TDD может уйти до двух лет! Это страшно. Особенно если учитывать, что у меня нет цели становиться профессиональным программистом.
Идеально, если на начальном этапе внедрения TDD вы не будете ограничены сроками. Первое время при внедрении TDD происходит значительное снижение скорости работы — где-то в 2-3 раза, поэтому многие разработчики срываются и пишут код без тестов. После того, как вы освоите большинство продвинутых методик тестирования, скорость снова возрастет и даже будет выше, чем раньше.
Думаю, следующий свой класс (класс для кэширования данных) я сейчас начну писать всё же снова без тестов. Вроде и хочется, но и колется.
Есть и ещё один фактор: я быстро загораюсь, но также быстро гасну. Мне необходимо писать класс на одной волне, иначе интерес может исчезнуть и кайф разработки превратится в длинную нудную рутину.
Что вы думаете про TDD? Используете? Как долго привыкали? Есть ли позитивный эффект в самые первые дни внедрения? Насколько сильно замедляется разработка в первое время?
Сделайте своей прекрасной половинке подарок – подарочный сертификат в лучший косметический салон Москвы. Ваша любимая будет без ума от счастья.
Комментарии
Комментирование этой статьи закрыто.
« Обновил AvisoDaos Анонс: скоро будет огромная заметка про ББББ »
Я примерно с начала октября пользуюсь unit-тестированием и могу сказать следующие вещи:
1) Это удобно, когда пишешь что-то сложное, но еще не дописал. С помощью unit-теста ты можешь протестировать только один модуль, а не откладывать это до написания всей системы. Следовательно баги фиксятся раньше и быстрее. Особенно это заметно при старте проекта.
2) Если где-то что-то нечаянно ломаешь, ты тут же это замечаешь на очередном прогоне тестов. И тут же чинишь.
3) Изначально пишешь систему так, чтобы ее было легко разобрать на части. И потом любую часть переиспользовать.
Единственная проблема unit-тестов – это то, что они отлавливают преимущественно предусмотренные баги, но таких примерно 70%.
PS. Если уж ты решил зарабатывать разработкой софта, профессиональным программистом тебе стать придется. Но это не значит, что тебе нужно оканчивать ВУЗ и получать корочки. Тебе надо набираться практики в смежных областях и желательно поглядывать на остальные. Это очень способствеут поиску удачных решений в основной области.
Это, кстати, основная функция академических ВУЗов, с той лишь разницей, что спектр знаний еще более широкий.
Ну, разработкой софта я временно зарабатываю, это уж точно не дело жизни. Интересно, затягивает, но всё же точно не то, чем хотел бы заниматься всегда.
Зря ты с этой статьи начал, она какая то пессимистичная. Как бы говорит «чтобы ты ни делал – это не правильно».
Лично я тесты использую чтобы писать код. Т.е. как обычно делают – пишут какой-то код, потом чтобы проверить его делаю вывод на экран промежуточных данных. Потом сам программист оценивает их правильность. Я же беру и возвращаю результат не на экран, а в строковую переменную. И делаю в тесте сравнение ожидаемой и реальной строки. И лично мне плевать правильно это или нет. Мне это помогает не тупить.
Не, я не с неё начал, на том сайте уже много чего прочитал. Просто чем больше читаю, тем большее уныние накатывает. Я всегда хочу всё здесь и сейчас, а не когда-то там через 1000 лет :)
Пишу тест только на определенный баг, после того как он был обнаружен.
По поводу как писать код, советую посмотреть доклад devpoint.ru/video/de…
.
Nugops, твой подход вообще ничего общего не имеет с TDD. Тесты в TDD пишутся до того, как пишется код. На видео не люблю тратить время, стенограмма доклада есть?
Лучше один раз увидеть :) Прикольное выступление, на Хабре проскакивало.
TDD не использую.
Ну ладно, раз и ты советуешь — посмотрю :) Che, не используешь и не планируешь? Какое отношение у тебя к этой методике, что думаешь о ней?
Хз. Полезно наверное там где много разработчиков и пишется что-то сложное, ну или если нет опыта проектирования (его придётся получать для написания тестов). Там в статье приводятся 4 обязательных книжки, если их прочитать и понять, вырастешь как программист и без тестов :)
Я сам ничего сложно не пишу, а в нашем проекте давно уже архитектура оттестирована.
Спасибо, к твоему мнению всегда прислушиваюсь. А ты все эти книжки читал? И если я прочитал Совершенный код, может быть эти четыре читать не надо? :) Я так понял, что Макконнелл сделал этакую компиляцию.
P.S. Ну вот, пока писал, ты позвонил. Ладно, пусть будет. В общем, про шаблоны точно почитать надо, наверно…
Хотя тоже опасность, так зашаблонизироваться можно совсем, не смогу свои велоспиеды придумывать. Меньше шансов перевернуть мир! :)
imho писать тесты до кода, нужно если у тебя большой проект и много програмистов, например в майкрософте на 1 програмиста приходится 1 тестировщик. А если ты один пишешь все, то можно обойтись и без них…
Тормоз да расслабься с этими тестами, самые нужные вещи все равно не оттестируешь в автоматическом режиме, либо оттестируешь но это будет очень сложно. Я лично тесты писал несколько раз всего и то в таких ситуаций где без них просто никак. Вот пример code.google.com/p/ht… (заметь ещё и без всяких PHPUnit позор мне). Там 17 тестов для одного единственного метода, если пробовать что то изменить без тестов – обязательно убьешь работающий функционал. В общем когда понадобится TDD подход к разработке сам поймешь.
Nugops, видео посмотрел, забавно :)
Jeck, да я вроде уж успокоился.
TDD это не серебренная пуля, он не нужен везде.
Сколько я не пытался применить TDD при разработке мобильных игр – ничего толком не выходит. Так отдельные подсистемы покрыть можно, но это дай бог 20% кода.
А вот при написании быстрой библиотеке перебора и определения покерных комбинаций – TDD даже у тебя, даже с нуля думаю даст офигенный прирост скорости разработки (я прям писал и радовался что с помощью TDD пишу)
Особенно на этапе оптимизации. Ибо если у тебя 100% покрытие тестами – то оптимизировать одно удовольсвие.
Поэтому ставить вопрос – а нужно ли использовать TDD вообще не корректно.
Можно ставить вопрос – а нужно ли использовать TDD при разработки вот этой конкретной программы. А еще лучше – вот этого конкретного модуля, или даже вот этого конкретного класса.
К сожалению, не всегда можно ответить на данный вопрос (особенно без опыта :) – но я не вижу почему бы данный опыт приобристи. TDD это не технический опыт, это сугубо организационный опыт. Это опыт подхода к задачи когда сначала определяются граничные условия, потом определяются необходимый результат, а потом делаются МИНИМАЛЬНО (боримся с перфекционизмом, ага) нужные дейсвия чтобы данный результат достигнуть.
Подобный подход помогает не только в программировании, а и по жизни вообще :)
А чисто технически – ну какая разница какой класс начинать писать – если ты уже продумал описанное выше, конечно.
Спасибо. Приятно читать мнение явно опытного программиста. Ты бы ещё ответил про Google Checkout в соседней заметке :)
[x] полезный комментарий :)
Правда быстрый перебор и определение покерных комбинаций реализовано в опенсорсном коде.
Ну если уж оффтопить –
Во первых, действительно есть – даже с unit тестами, во-вторых у меня полчилось раз в 10 быстрее, в третьих как выяснилось проще для каждого уникально набора из N карт посчитать готовые комбинации которые там есть и загнать все в память – благо ее сейчас много.
Но вот чтобы поверить что табличка верная все равно нужны тесты :)