внедрение TDD уже на существующем коде
#1
Отправлено 05 февраля 2010 - 15:13
Кто-нибудь внедрял TDD (test-driven development) на производстве? Понятно, что это дело менеджера, но так получилось, что это необходимо в 1-ю очередь мне.
Возникает 2 вопроса.
1) как убедить разработчиков перейти в TDD? Некоторые из них его поддерживают, некоторые нет. Статьи в Интернете говорят о полезности, но при этом разработчики не всегда хотят тратить время на сопровождение тестов.
2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.
#2
Отправлено 05 февраля 2010 - 16:46
Убеждать разработчиков должен спонсор.Коллеги!
Кто-нибудь внедрял TDD (test-driven development) на производстве? Понятно, что это дело менеджера, но так получилось, что это необходимо в 1-ю очередь мне.
Возникает 2 вопроса.
1) как убедить разработчиков перейти в TDD? Некоторые из них его поддерживают, некоторые нет.
Достаточно убедить спонсора, что эта методология себя окупит.
Еще в Интернете полно статей про то, что не бывает серебрянных пуль :-)Статьи в Интернете говорят о полезности, но при этом разработчики не всегда хотят тратить время на сопровождение тестов.
Можно внедрять и локально. Написать тесты на весь существующий код - остановить разработку на заметное время.2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
Новые независимые модули - вполне реалистично.
Сомнения есть не только из-за этого.И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.
Расходы на TDD можно оценить - снижение скорости написания кода раза в 3-4 на момент внедрения (пара-тройка месяцев точно) и раза в полтора в штатном режиме.
Какие проблемы ожидается закрыть TDD?
Стоят ли они того?
Если в TDD поиграться, а потом бросить до завершения проекта, то это будут чистые убытки.
#3
Отправлено 05 февраля 2010 - 21:08
И даже есть статьи, опровергающие доказательства эффективности ТДД по сравнению с написанием unit-тестов после написания кода. Например, эта:Еще в Интернете полно статей про то, что не бывает серебрянных пуль :-)Статьи в Интернете говорят о полезности, но при этом разработчики не всегда хотят тратить время на сопровождение тестов.
TDD Proven Effective! Or is it?
Для написанного уже кода можно будет написать тесты в процессе его рефакторинга. Если же рефакторинга или изменений в нем не предполагается, то не очень ясна необходимость юнит-тестов для этого кода.Можно внедрять и локально. Написать тесты на весь существующий код - остановить разработку на заметное время.2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
Новые независимые модули - вполне реалистично.
SQL для тестировщиков
Тренинги по HP QTP и автоматизации тестирования
Если минарет, значит выше всех (с)
#4
Отправлено 05 февраля 2010 - 22:48
Всё достаточно просто.Кто-нибудь внедрял TDD (test-driven development) на производстве? Понятно, что это дело менеджера, но так получилось, что это необходимо в 1-ю очередь мне.
TDD появляется только тогда, когда появляется хоть кто-то, кто это умеет. Или учится. Просто так сказать: "а давайте теперь писать модульные тесты, правда я не знаю как" - не поможет. Даже в проектах, где менеджмент требует такой активности, тесты просто так не появляются.
Заявление о том, что TDD тормозит разработку, мягко говоря, не очень корректно. Проекты разные, люди разные. Я лично вполне представляю себе ситуацию, когда TDD разработку ускоряет.
При работе с существующей системой могут быть следующие ситуации:
1. Готовый код, который не планируется менять. Тесты тут не появятся никогда
2. Готовый код, в который нужно внести изменения. В этой ситуации предварительное прикрытие существующей функциональности тестами может снизить риски при внесении изменений. Исключение составляет следующий пункт
3. Система с большим техническим долгом. Иногда код пишется так, что для тестирования его надо выбросить и переписать заново. Появление тестов практически невероятно.
4. Новая функциональность. Идеальные условия, если нет влияния пункта 3.
Резюме: практики типа TDD плохо внедряются распоряжениями сверху. Хорошо будет работать методика завлечения. Для этого надо либо найти готового разработчика с хорошим опытом тестирования и лидерскими наклонностями, либо
1. Разобраться в модульном тестировании самому.
2. Написать несколько тестов, воспроизводящих известные проблемы. Продемонстрировать разработчику, что такой подход упрощает отладку и внесение изменений.
3. Для новой функциональности - написать тесты, показать, как они помогают ускорить проектирование и разработку
Повторюсь - если есть желание внедрить TDD, нельзя приходить к разработчикам с пустыми руками. Подход "смотри какие я тесты написал" работает лучше, чем "я слышал что надо писать юнит-тесты".
В конце концов, действительно, надо четко понимать цель. Внедрение TDD - не цель, а средство.
#5
Отправлено 06 февраля 2010 - 09:25
Скорость разработки при этом может и возрасти.
С моей точки зрения, TDD - очень дорогая методология, ее стоит внедрять, когда более дешевые варианты уже выбраны.
Заявление о том, что TDD тормозит разработку, мягко говоря, не очень корректно. Проекты разные, люди разные. Я лично вполне представляю себе ситуацию, когда TDD разработку ускоряет.
#6
Отправлено 06 февраля 2010 - 13:13
Если TDD снижает скорость написания ненужного кода - она себя окупает.На всякий случай - я говорил о скорости написания кода, я не скорости разработки :-)
Скорость разработки при этом может и возрасти.
С моей точки зрения, TDD - очень дорогая методология, ее стоит внедрять, когда более дешевые варианты уже выбраны.
Дороговизну/дешевизну определенно можно измерить на конкретных примерах, наверное.
#7
Отправлено 07 февраля 2010 - 21:30
Никак. Т.е. совсем никак. Исходя из определения. Давайте еще раз прочитаем, что такое TDD. TDD - это .... ля-ля-ля...2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.
А то, что вы хотите, это покрытие кода юнит тестами. Совсем другой коленкор. И делается совсем по другому. Совсем по другому. Сделать можно. Но нужны другие методики. Так что вы пока определитесь чего хотите.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#8
Отправлено 08 февраля 2010 - 01:16
Все-таки, когда мы вносим изменения в существующий код (исправление ошибок, изменение функциональности), эта активность может быть test-driven (тесты на существующий код + на новый код), либо confidence-driven ("всё у нас получится"). Я бы этот вариант тоже учитывал.А то, что вы хотите, это покрытие кода юнит тестами. Совсем другой коленкор. И делается совсем по другому. Совсем по другому. Сделать можно. Но нужны другие методики. Так что вы пока определитесь чего хотите.
#9
Отправлено 08 февраля 2010 - 07:33
Никак. Т.е. совсем никак. Исходя из определения. Давайте еще раз прочитаем, что такое TDD. TDD - это .... ля-ля-ля...2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.
А то, что вы хотите, это покрытие кода юнит тестами. Совсем другой коленкор. И делается совсем по другому. Совсем по другому. Сделать можно. Но нужны другие методики. Так что вы пока определитесь чего хотите.
насчет делается совсем по другому я знаю, поэтому и написал в конце о пользе такого внедрения. Польза от внедрения TDD видится в том, что будет видна логика работы программы, т.к. сейчас продукт активно разрабатывается, поэтому сложно отследить что и как делают модули системы. Поэтому будет легче тестировать, т.к. часть очевидных ошибок будет исправляться на этапе разработки.
Т.е. хочется не просто, чтобы по завершении какого-то этапа разработки сразу отдавали в тестирование, а сначала проверили сами на наличие логических ошибок путем прогона юнит-тестов.
Да, возможно внедрение TDD на новый код, но что тогда делать со старым? Ждать когда будет очередной рефакторинг?
SALar, судя по вашим постам вы видимо в этом хорошо разбираетесь. Что бы вы сделали на моем месте?
#10
Отправлено 08 февраля 2010 - 07:46
Всё достаточно просто.Кто-нибудь внедрял TDD (test-driven development) на производстве? Понятно, что это дело менеджера, но так получилось, что это необходимо в 1-ю очередь мне.
TDD появляется только тогда, когда появляется хоть кто-то, кто это умеет. Или учится. Просто так сказать: "а давайте теперь писать модульные тесты, правда я не знаю как" - не поможет. Даже в проектах, где менеджмент требует такой активности, тесты просто так не появляются.
Заявление о том, что TDD тормозит разработку, мягко говоря, не очень корректно. Проекты разные, люди разные. Я лично вполне представляю себе ситуацию, когда TDD разработку ускоряет.
При работе с существующей системой могут быть следующие ситуации:
1. Готовый код, который не планируется менять. Тесты тут не появятся никогда
2. Готовый код, в который нужно внести изменения. В этой ситуации предварительное прикрытие существующей функциональности тестами может снизить риски при внесении изменений. Исключение составляет следующий пункт
3. Система с большим техническим долгом. Иногда код пишется так, что для тестирования его надо выбросить и переписать заново. Появление тестов практически невероятно.
4. Новая функциональность. Идеальные условия, если нет влияния пункта 3.
Резюме: практики типа TDD плохо внедряются распоряжениями сверху. Хорошо будет работать методика завлечения. Для этого надо либо найти готового разработчика с хорошим опытом тестирования и лидерскими наклонностями, либо
1. Разобраться в модульном тестировании самому.
2. Написать несколько тестов, воспроизводящих известные проблемы. Продемонстрировать разработчику, что такой подход упрощает отладку и внесение изменений.
3. Для новой функциональности - написать тесты, показать, как они помогают ускорить проектирование и разработку
Повторюсь - если есть желание внедрить TDD, нельзя приходить к разработчикам с пустыми руками. Подход "смотри какие я тесты написал" работает лучше, чем "я слышал что надо писать юнит-тесты".
В конце концов, действительно, надо четко понимать цель. Внедрение TDD - не цель, а средство.
спасибо,
действительно уже есть тесты, которые покрывают часть модулей, и они нашли несколько багов, но уже понял, что один со всем не справлюсь, а перекладывать модульное тестирование на плечи тестировщиков считаю неправильным (хотя может есть обратные примеры?).
Есть также функциональные тесты, которые работают с модулями как с черным ящиком. Но ограничиваться на них одних очевидно неправильно.
Вижу 2 выхода:
1) либо внедрение TDD, собственно говоря о чем этот пост
2) либо написание интеграционных тестов (которые похожи на юнит тесты, но при этом без заглушек и моков), которые бы проверяли взаимодействие модулей между собой, и fuzzy тестирование с проверкой того, как будут вести себя модули при подаче разного рода входных данных.
Хочу заметить, что 1-й пункт не отменяет 2-го, но при этом значительно упрощает реализацию 2-го пункта.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных