Должен ли я использовать TDD?

Question

Я единственный разработчик в моей (очень маленькой) компании, и я собираюсь начать работу с веб-приложением ASP.NET среднего размера для указанной компании.

Я пытаюсь выяснить, стоит ли мне изучать Test Driven Development (TDD) и реализовывать его в этом приложении.

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

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

Answer 1

Калеб - Я хотел представить сайт, который был создан для самостоятельного изучения TDD дома Вы учитесь лучше, если не находитесь под давлением. Просто Google для "tdd-problem", и вы найдете его.

Answer 2

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

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

Answer 3

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

Легко сказать "это приложение с графическим интерфейсом! Невозможно протестировать мои вещи"! Это может быть самоисполняющимся пророчеством. Конечно, вы не можете легко протестировать макет всех ваших виджетов, но какая часть вашей программы связана с тем, как выложены ваши виджеты? Вы можете помешать себе делать хороший TDD, потому что какой-то аспект слишком тесно связан с компоновкой ваших виджетов GUI, или он слишком тесно связан с чем-то другим, что не легко проверить. Остановись и брось вызов себе - действительно ли это так? Могу ли я разделять и модульно кодировать мой код, чтобы его можно было лучше изолировать от этих частей системы? Уместно ли это делать (приносят ли результаты испытания юнитом стоимость?). Не принимайте карт-бланш, поскольку это невозможно только потому, что ваше программное обеспечение привязано к не унитестируемым компонентам.

Answer 4

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

Answer 5

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

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

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

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

Может быть, стоит попробовать несколько TDD Katas дома, чтобы ознакомиться с ним, прежде чем использовать его на работе.

Здесь можно найти несколько хороших катас здесь