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

Из-за изменившихся требований меня попросили изменить модуль, который я ранее написал, и он довольно слабо связан (не так много, как хотелось бы, но насколько я могу получить, не вводя много других концепций). Я решил включить набор модульных тестов с моим пересмотренным кодом, чтобы «доказать», что он работает, как ожидалось, и продемонстрировать, как работает тестирование; Я не следую истинному TDD, так как часть кода уже написана, но я надеюсь следовать некоторым концепциям TDD для нового кода, который мне придется создать.

Теперь неизбежно я уверен, что меня спросят, почему на написание кода у меня уходит больше дня или двух, поскольку части того, с чем я буду взаимодействовать, уже существуют в системе (хотя и без каких-либо тестов и очень жестко). в сочетании), и когда я проверяю код, меня спросят, что это за проект «Тесты». Я могу объяснить основы тестирования, но не могу объяснить фактические преимущества так, как это поняли бы другие (потому что они считают, что тестирование требует, чтобы вы запускали приложение самостоятельно, поскольку зачастую фактический пользовательский интерфейс важен для определения, работает ли эта функция). " или не). Они не понимают идею слабой связи (ясно видно из того факта, что ничто не является слабосвязанным; кроме написанного мною кода нет никаких интерфейсов), так что попытка использовать это в качестве выгоды, вероятно, принесет мне "А?" вид, и снова я не могу быть настолько свободным, как хотелось бы, без необходимости переделывать несколько существующих модулей и, возможно, представить какой-то контейнер IoC, который будет рассматриваться как напрасная трата времени, а не как «программирование».

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

Я хочу представить концепцию модульных тестов (и тестирование в целом) моим коллегам

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

В такой ситуации я бы просто начал писать свои маленькие модульные тесты, не пытаясь сначала объяснить кому-либо слишком много. Добавляйте пару из них всякий раз, когда я изменяю код, не пытаясь полностью охватить весь код (что займет слишком много времени). В идеале, если мне удастся достичь точного баланса, к тому времени, когда они заметят, что я пишу модульные тесты, у меня уже может быть существенный набор тестов и некоторые конкретные результаты, которые нужно показать (например, «в этом тестовом примере мне удалось обнаружить ошибку). введены изменения на прошлой неделе, которые в противном случае проскочили бы в QA / производство "). Это докажет ценность тестов для любого серьезного разработчика.

После этого я могу начать объяснять долгосрочные преимущества модульного тестирования, такие как

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

См. Также эту связанную ветку: Автоматическое модульное тестирование, интеграционное тестирование или приемочное тестирование .

И более ранний от SO: Что такое модульное тестирование?

Рефакторинг без страха

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

• «Я не хочу трогать этот код, потому что боюсь, что сломаю его»
• «Я не хочу писать новую функциональность для этого кода, потому что я не знаю, как он работает»
• «Тайно, я боюсь этого кода»

Я мог бы говорить больше, но это хорошо освещено, например, дядя Боб на TDD и Мартин Фаулер на TDD .

зависимости

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

Боб: «О, с% ^ p! Боссы просто заставили нас всех использовать MS SQL Server 2008» Джейн: «Все в порядке, ущерб минимизирован, потому что мы DI наш источник данных и наши классы DAO, я так рад, что TDD поощряет нас по этому пути. "

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

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

Делать математику

• t _mt = время, необходимое для ручного тестирования всего, на что вы, возможно, можете повлиять
• t _wt = время, необходимое для написания тестов

• k = сколько раз вам, вероятно, придется все тестировать, прежде чем выпускать новый код

  если (t _wt <t _mt ) или (t _wt <(k * t _mt )), то это не сложно: написание тестов ускорит разработку.

в противном случае посмотрите на соотношение (t _wt / (k * t _mt )). Если это очень большое число, тогда ждите другой возможности; в противном случае это оправдано преимуществами регрессионного тестирования.

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

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

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

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

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

Ключевое слово здесь - эволюция, а не революция.