Должен ли я начать использовать TDD в проекте, который еще не использует его

Question

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

Теперь я начал проект около 12 месяцев назад, но я работал над ним только слегка, я только начал уделять ему гораздо больше времени (почти каждую ночь).

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

Итак, вопрос в том, считаете ли вы хорошей идеей начать использовать TDD в проекте, который еще не использует его.

РЕДАКТИРОВАТЬ: Я только добавил немного, чтобы прояснить, что я имею в виду под борьбой с «чувством направления», это было бы не лучшим решением без разъяснений.

Answer 1

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

Однако ... (всегда есть "но") ...

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

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

Answer 2

Да.

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

Может быть, стоит взглянуть на Разработка приложений Brownfield в .NET ? Он полон практических и практических советов именно для этого сценария (одно из определений, предложенных для «Brownfield», - «без надлежащих модульных тестов»).

Answer 3

Да, абсолютно хорошая идея начать заниматься TDD.

Вы заплатите стартовую сумму как минимум по двум причинам:

1. Обучение новому навыку TDD / юнит-тестирование.
2. Модернизация вашего кода для тестирования.

Вам нужно будет выполнить некоторые из этих двух действий, но, работая, если вы обнаружите, что боретесь, подумайте, какой из этих двух является источником усилий.

Но конечный результат того стоит. Из того, что вы описываете, это проект, с которым вы собираетесь жить довольно долго. Помните об этом, когда вы теряете час здесь или там. Через год вы будете очень рады, что вложили эти средства как в свой набор навыков, так и в базу кода.

Answer 4

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

Хотя вы новичок в этой технике, вам, вероятно, следует сконцентрироваться на ее использовании для кода, который вы пишете с чистого листа - новые классы, новые методы и т. Д. Как только вы освоитесь, начните писать тесты для кода что вы меняете.

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

Если вам не хватает чувства направления, я сомневаюсь, что TDD вам очень поможет. Возможно, вы захотите взглянуть на Acceptance Testing, который по крайней мере так же важен, как модульное тестирование, и поможет вам сосредоточиться на функциональности системы, а не на отдельных единицах кода. Книга TDD Лассе Коскела - хорошее введение в обе методики.

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

Answer 5

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

Answer 6

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

• Воспользуйтесь преимуществом правила 80:20, запустите профилировщик и поместите контрольные примеры в наиболее часто вызываемый фрагмент кода.
• Поместите тесты вокруг дома драгоценности, кишки, самый важный код.
• Поместите тесты вокруг надоедливого, постоянно ломающегося, повторяющегося глючного кода дежавю.
• Поместите тесты вокруг всех ошибок, с которыми вы столкнулись до того, как исправит ошибку, провалив тест.

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

Если вы все еще любите юнит-тесты в этот момент, вы будете Красным, Зеленым, самостоятельно выполняющим рефакторинг.

Answer 7

Да.

TDD облегчает понимание кода другими людьми, а также улучшает приложение с течением времени

Answer 8

Как уже говорили другие, TDD не должен наносить ущерб проекту в процессе реализации, но подумайте внимательно, если у вас возникнет желание провести масштабный рефакторинг, чтобы просто провести тестирование. Убедитесь, что преимущества оправдывают затраты.

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

Answer 9

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

Answer 10

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

Мой подход к вводу среднего потока TDD был:

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

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