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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

Да.

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

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

Ответ 3

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

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

  • Изучение нового умения TDD/модульного тестирования.
  • Модернизация вашего кода для проверки.

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

Ответ 7

Да.

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

Ответ 8

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

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

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

Если вы по-прежнему любите юнит-тесты на этом этапе, вы будете сами по себе Red, Green, Refactoring.

Ответ 9

Совершенно верно.

Внесите TDD в новый код и, если позволяет время, введите "Comment Driven Design" с вашим существующим кодом, если он еще не протестирован.

  • Комментируйте блок существующего кода, который необходимо проверить
  • Напишите свой тест
  • Раскомментируйте свой исходный код за один оператор за раз (если у вас есть блок if, раскомментируйте весь блок)
  • Определите, будет ли ваш исходный код в конечном итоге проходить ваш тест, а если нет, перепишите его, чтобы передать ваши тесты.

Ответ 10

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

Мой подход к созданию промежуточного потока TDD состоял в следующем:

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

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

Ответ 11

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