Сообщений в теме: 9

[samurai08]

Коллеги!

Кто-нибудь внедрял TDD (test-driven development) на производстве? Понятно, что это дело менеджера, но так получилось, что это необходимо в 1-ю очередь мне.
Возникает 2 вопроса.
1) как убедить разработчиков перейти в TDD? Некоторые из них его поддерживают, некоторые нет. Статьи в Интернете говорят о полезности, но при этом разработчики не всегда хотят тратить время на сопровождение тестов.
2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.

[DrVal]

Коллеги!

Кто-нибудь внедрял TDD (test-driven development) на производстве? Понятно, что это дело менеджера, но так получилось, что это необходимо в 1-ю очередь мне.
Возникает 2 вопроса.
1) как убедить разработчиков перейти в TDD? Некоторые из них его поддерживают, некоторые нет.

Убеждать разработчиков должен спонсор.
Достаточно убедить спонсора, что эта методология себя окупит.

Статьи в Интернете говорят о полезности, но при этом разработчики не всегда хотят тратить время на сопровождение тестов.

Еще в Интернете полно статей про то, что не бывает серебрянных пуль :-)

2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.

Можно внедрять и локально. Написать тесты на весь существующий код - остановить разработку на заметное время.
Новые независимые модули - вполне реалистично.

И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.

Сомнения есть не только из-за этого.
Расходы на TDD можно оценить - снижение скорости написания кода раза в 3-4 на момент внедрения (пара-тройка месяцев точно) и раза в полтора в штатном режиме.
Какие проблемы ожидается закрыть TDD?
Стоят ли они того?
Если в TDD поиграться, а потом бросить до завершения проекта, то это будут чистые убытки.

[ch_ip]

Статьи в Интернете говорят о полезности, но при этом разработчики не всегда хотят тратить время на сопровождение тестов.

Еще в Интернете полно статей про то, что не бывает серебрянных пуль :-)

И даже есть статьи, опровергающие доказательства эффективности ТДД по сравнению с написанием unit-тестов после написания кода. Например, эта:
TDD Proven Effective! Or is it?

2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.

Можно внедрять и локально. Написать тесты на весь существующий код - остановить разработку на заметное время.
Новые независимые модули - вполне реалистично.

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

[rlabs]

Кто-нибудь внедрял TDD (test-driven development) на производстве? Понятно, что это дело менеджера, но так получилось, что это необходимо в 1-ю очередь мне.

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

Заявление о том, что TDD тормозит разработку, мягко говоря, не очень корректно. Проекты разные, люди разные. Я лично вполне представляю себе ситуацию, когда TDD разработку ускоряет.

При работе с существующей системой могут быть следующие ситуации:
1. Готовый код, который не планируется менять. Тесты тут не появятся никогда
2. Готовый код, в который нужно внести изменения. В этой ситуации предварительное прикрытие существующей функциональности тестами может снизить риски при внесении изменений. Исключение составляет следующий пункт
3. Система с большим техническим долгом. Иногда код пишется так, что для тестирования его надо выбросить и переписать заново. Появление тестов практически невероятно.
4. Новая функциональность. Идеальные условия, если нет влияния пункта 3.

Резюме: практики типа TDD плохо внедряются распоряжениями сверху. Хорошо будет работать методика завлечения. Для этого надо либо найти готового разработчика с хорошим опытом тестирования и лидерскими наклонностями, либо
1. Разобраться в модульном тестировании самому.
2. Написать несколько тестов, воспроизводящих известные проблемы. Продемонстрировать разработчику, что такой подход упрощает отладку и внесение изменений.
3. Для новой функциональности - написать тесты, показать, как они помогают ускорить проектирование и разработку

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

В конце концов, действительно, надо четко понимать цель. Внедрение TDD - не цель, а средство.

[DrVal]

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

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

Заявление о том, что TDD тормозит разработку, мягко говоря, не очень корректно. Проекты разные, люди разные. Я лично вполне представляю себе ситуацию, когда TDD разработку ускоряет.

[rlabs]

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

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

Если TDD снижает скорость написания ненужного кода - она себя окупает.

Дороговизну/дешевизну определенно можно измерить на конкретных примерах, наверное.

[SALar]

2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.

Никак. Т.е. совсем никак. Исходя из определения. Давайте еще раз прочитаем, что такое TDD. TDD - это .... ля-ля-ля...


А то, что вы хотите, это покрытие кода юнит тестами. Совсем другой коленкор. И делается совсем по другому. Совсем по другому. Сделать можно. Но нужны другие методики. Так что вы пока определитесь чего хотите.

[rlabs]

А то, что вы хотите, это покрытие кода юнит тестами. Совсем другой коленкор. И делается совсем по другому. Совсем по другому. Сделать можно. Но нужны другие методики. Так что вы пока определитесь чего хотите.

Все-таки, когда мы вносим изменения в существующий код (исправление ошибок, изменение функциональности), эта активность может быть test-driven (тесты на существующий код + на новый код), либо confidence-driven ("всё у нас получится"). Я бы этот вариант тоже учитывал.

[samurai08]

2) как внедрять TDD на существующем коде? т.е. большая часть кода уже написана и надо либо писать тесты для этого кода, либо надо внедрять TDD для нового кода. В общем, не совсем понятно.
И вообще из-за этого возникает сомнение в пользе применении TDD на существующем коде.

Никак. Т.е. совсем никак. Исходя из определения. Давайте еще раз прочитаем, что такое TDD. TDD - это .... ля-ля-ля...


А то, что вы хотите, это покрытие кода юнит тестами. Совсем другой коленкор. И делается совсем по другому. Совсем по другому. Сделать можно. Но нужны другие методики. Так что вы пока определитесь чего хотите.

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

Да, возможно внедрение TDD на новый код, но что тогда делать со старым? Ждать когда будет очередной рефакторинг?

SALar, судя по вашим постам вы видимо в этом хорошо разбираетесь. Что бы вы сделали на моем месте?

[samurai08]

Кто-нибудь внедрял 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-го пункта.