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

Я хочу сказать, что многие из новых методов разработки программного обеспечения работают только при совместном использовании. В частности, MVC, ORM, IoC, модульное тестирование и Mocking. DDD (в современном примитивном смысле) и TDD / BDD более независимы, поэтому вы можете использовать их или нет.

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

Альтернативой является то, что когда ваш Изменения в структуре, вы не тестируете изменения. Или вы вообще не тестируете Framework. Это то, что вы хотите?

Вы можете попробовать рефакторинг вашего Framework, чтобы он состоял из более мелких частей, которые можно было протестировать независимо. Затем, когда ваша структура изменится, вы надеетесь, что либо (а) изменится меньше частей, либо (б) изменения в основном касаются способов составления частей. В любом случае вы сможете лучше повторно использовать и код, и тесты. Но здесь требуется настоящее интеллектуальное усилие; не ждите, что это будет легко.

Почему вам нужно менять модульные тесты каждый раз, когда вы вносите изменения в свою структуру? Разве не должно быть наоборот?

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

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

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

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

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

Не делайте этого. сдавайся, пока это расстраивает, выгода будет реализована.

Не делайте этого. сдавайся, пока это расстраивает, выгода будет реализована.

Не делайте этого. сдавайся, пока это расстраивает, выгода будет реализована.

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

Хороший вопрос!

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

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

HTH

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

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

1233] Будете признательны, если вы хорошо поделитесь своим примером, и тогда мы сможем больше узнать о проблемной области?

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

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

Хорошая идея - попытаться классифицировать сбои, которые вы видите. Какие у вас проблемы? Например, это обслуживание тестов (например, их компиляция после рефакторинга!) Из-за изменений API, или это связано с изменением поведения API? Если вы видите шаблон, вы можете попробовать изменить дизайн производственного кода или лучше изолировать тесты от изменений.

Если изменение нескольких вещей приводит к неописуемым разрушениям в вашем наборе тестов во многих местах, вы можете сделать несколько вещей (большинство из них - просто общие советы по модульному тестированию): небольшие блоки кода. Извлечь интерфейсы или базовые классы, где это имеет смысл, так что единицы кода в них есть «швы». Чем больше зависимости, которые вы должны втянуть (или хуже, создать экземпляр внутри класса используя "новый"), тем более подвержены поменять код будет. Если каждый единица кода имеет несколько зависимости (иногда пара или совсем нет) тогда лучше изолированы от изменений.

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

Тестируете ли вы достаточно маленькие блоки кода? Вы не должны видеть слишком много изменений, если вы не меняете фундаментально все в своем основном коде.

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

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

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

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

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

Рассмотрите возможность использования рефакторинга метода extract для выдергивать небольшие блоки кода, которые делают одно и только одно; без зависимостей и напишите свои тесты на эти небольшие методы.

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

Вы должны тестировать интерфейсы, а не внутреннюю реализацию.

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

Вы должны тестировать интерфейсы, а не внутреннюю реализацию.

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

Вы должны тестировать интерфейсы, а не внутреннюю реализацию.

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

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

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

Однако с хорошо подготовленными тестами на основе разработчиков вы также сможете проверить целостность системы.

Надеюсь, это поможет.

Если проблема в том, что ваши тесты устаревают с фактическим кодом, вы можете сделать одно или оба из следующих:

1. Обучите всех разработчиков не проходить проверку кода, который не обновить модульные тесты.
2. Настройте автоматическое тестовое окно, которое запускает полный набор модульных тестов после каждой регистрации и отправляет электронные письма тем, кто нарушает сборку. (Раньше мы думали, что это только для «больших парней», но мы использовали пакет с открытым исходным кодом на выделенной коробке.)

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

• Использование конкретных классов вместо интерфейсов
• Использование одиночных объектов
• Вместо вызова множества статических методов для бизнес-логики и доступа к данным методов интерфейса

Из-за этого я обнаружил, что обычно мои тесты ломались - не из-за изменения в тестируемом классе, а из-за изменений в других классах, которые вызывали тестируемый класс. В основном, рефакторинг классов для запроса их зависимостей данных и тестирование с помощью имитирующих объектов (EasyMock et al для Java) делает тестирование более целенаправленным и удобным в обслуживании. Мне очень понравились некоторые сайты, особенно по этой теме:

• Блог тестирования Google
• Руководство по написанию тестируемого кода