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

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

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

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

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

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

Дополнительное время разработки, о котором вы говорите, может быть иллюзией .

Отличие TDD от стандартного модульного тестирования заключается в том, что он используется не только для тестирования.

TDD is a new way of developing software, Это один из лучших способов, которые я знаю.

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

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

распространенное заблуждение, позвольте мне выкрикнуть это:

ИСПЫТАНИЯ В TDD ДЛЯ ОСОБЕННОСТЕЙ

МЫ.

Изменить: позвольте мне уточнить: «написание ... модульные тесты для всех или наших компонентов» является модульное тестирование , а не TDD. Я обычно использую TDD в командах с одним человеком с большим успехом; выплата экстраординарна.

Есть замечательная книга по TDD, Искусство модульного тестирования ( официальный сайт ), в которой есть примеры в .net с java-версией. Хорошая часть заключается в том, что есть целые главы, в которых рассматриваются такие вопросы, как «Интеграция модульного тестирования в организацию» - Глава 8 и «Работа с устаревшим кодом» - Глава 9. Хотя я не эксперт в этой области (пока :-)) Исходя из моего опыта, я считаю, что это хорошая отправная точка.

Есть пара вопросов, на которые нужно получить ответы:

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

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

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

Когда люди говорят мне о том, чтобы начать применять тестирование в своей команде, я всегда сначала проверяю, как будут выполняться тесты. Часто команды не имеют непрерывной сборки на месте. Если у вас ограниченные ресурсы, я бы посоветовал, что настройка CI-сервера является обязательным условием для начала любого серьезного набега на тестирование.

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

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

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

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

Итог - медленное развитие, но мало дефектов, а значит, гораздо меньше времени на исправление ошибок.

Вот где я думаю, что Behavior Driven Development демонстрирует немедленные выгоды, но я не уверен, что разработка, управляемая тестами, делает это.

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

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

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

Это также может помочь восприятию вашей команды другими людьми: если вы сядете и определите, что нужно сделать в системе, вы можете перейти от «идиотов, которые перерабатывают все и тратят время на вещи, которые мы не просили», чтобы, «умные люди, которые придумывают полезные функции».

TL; DR: Поведение, управляемое поведением, может быстро показать улучшения, потому что оно ориентировано на клиента. Мне кажется, что разработка через тестирование заключается в тестировании внутренних компонентов кодовой базы, о которых «никто» не заботится, и дает менее очевидные преимущества для бизнеса. (Поведение, управляемое поведением, имеет непосредственное, на ваш взгляд, изменение: у инженеров внезапно появляется гораздо больше времени, чтобы «клиент» или бизнес-аналитик попытался сделать это правильно - что следует рассматривать как хорошую вещь ». , у них встреча о Feature X, что означает прогресс в этом направлении! ")