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

Question

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

Answer 1

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

• Получите хотя бы одну копию Эффективная работа с устаревшим кодом Майкла Фезерса и пройдите его вместе с людьми из команды.Это касается именно этой проблемы.
• Обеспечение строгой политики модульного тестирования (предпочтительно TDD) для всего нового кода, который пишется.Это гарантирует, что новый код не станет унаследованным кодом, а получение нового кода для тестирования приведет к рефакторингу старого кода для тестирования.
• Если у вас есть время (которого у вас, вероятно, нет), напишитеНесколько ключевых интеграционных тестов на критических путях вашей системы.Это хорошая проверка, что рефакторинг, который вы выполняете на шаге № 2, не нарушает основной функциональности.

Answer 2

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

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

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

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

Answer 3

Интеграционные тесты играют важную роль, но центральным для тестирования вашего кода являются юнит-тесты.

В начале вы, вероятно, будете вынуждены проводить только интеграционные тесты. Причина в том, что ваша кодовая база очень сильно связана (просто дикая догадка, так как нет модульных тестов). Тесная связь означает, что вы не можете создать экземпляр объекта для тестирования, не создавая сначала много связанных объектов. Это делает любые тесты интеграционными тестами по определению. Очень важно, чтобы вы написали эти интеграционные тесты, так как они должны использоваться в качестве базовых линий для ваших усилий по поиску ошибок / рефакторингу.

1. Напишите тесты, которые документируют ошибку.

2. Исправьте ошибку, чтобы все созданные юнит-тесты были зелеными.

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

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

5. Наконец, когда вы отсоединили класс, вы можете отсоединить и тесты. Теперь, когда вы вводите интерфейс вместо создания конкретных экземпляров внутри тестируемого класса, вы можете вместо этого создавать заглушки / насмешки. Внезапно ваши тесты стали юнит-тестами !!

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

Answer 4

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

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

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