Почему использование тестов интеграции вместо модульных тестов - плохая идея?

Ответ 1

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

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

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

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

Мы не мечтали бы заменить наши модульные тесты интеграционными тестами, поскольку:

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

^(a) См., Например, http://slideshare.net/Vamsipothuri/defect-prevention, слайд № 5 или найдите в сети Defect prevention : Reducing costs and enhancing quality.

Ответ 2

Тесты интеграции говорят вам, работает ли он. Модульные тесты говорят вам, что не работает. Пока все работает, вам не нужны "единичные тесты", но когда-то что-то не так, очень приятно, что unit test указывает на проблему. Как вы говорите, они служат различным целям; хорошо иметь оба.

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

В основном я выполняю модульные тесты и в 10 раз меньше интеграционных тестов (конфигурация, запросы).

Ответ 6

Все о сокращении времени итерации.

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

Оба явно полезны, так как оба обнаружат проблемы, которые другие не могут обнаружить.

OTOH, из "чистого" подхода TDD, модульные тесты - это не тесты, а спецификации функциональности. Тесты интеграции, OTOH, действительно "проверяют" в более традиционном понимании этого слова.

Ответ 7

Два типа тестов разные. Модульные тесты, на мой взгляд, не являются альтернативой интеграционным испытаниям. Главным образом потому, что интеграционные тесты, как правило, специфичны для контекста. У вас может быть сценарий, при котором unit test терпит неудачу, а ваша интеграция не будет и наоборот. Если вы внедряете неверную бизнес-логику в классе, который использует многие другие компоненты, вы бы хотели, чтобы ваши тесты интеграции отображали их, ваши модульные тесты не обращают внимания на это. Я понимаю, что интеграционное тестирование выполняется быстро и просто. Я бы сказал, что вы полагаетесь на свои модульные тесты каждый раз, когда вы вносите изменения в свою кодовую базу, а наличие списка зелени даст вам больше уверенности в том, что вы не нарушили ожидаемое поведение на уровне отдельного класса. Единичные тесты дают вам тест против одного класса, он делает то, что он должен был сделать. Тесты интеграции проверяют, что несколько классов, работающих вместе, делают то, что вы ожидаете от них, для этого конкретного экземпляра совместной работы. В этом и состоит вся идея разработки OO: отдельные классы, которые инкапсулируют конкретную логику, что позволяет повторно использовать.

Ответ 8

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

Нет смысла тестировать, как шестерни машины вращаются вместе, если механизмы могут быть сломаны.

Ответ 9

Я думаю, что основной проблемой является освещение.

A unit test определенного небольшого компонента, такого как метод или не более класса, должен тестировать этот компонент в каждом правовом сценарии (разумеется, один абстрактный класс эквивалентности, но каждый основной должен быть рассмотрен). В результате в этот момент следует уловить изменение, которое нарушает установленную спецификацию.

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

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

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

Ответ 10

A unit test записывается для проверки метода в классе. Если этот класс зависит от любого внешнего ресурса или поведения, вы должны издеваться над ними, чтобы убедиться, что вы тестируете только один класс. В unit test не должно быть внешних ресурсов.

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

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

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

Ответ 11

• Модульные тесты сосредоточены на тестировании отдельного компонента и не зависят от внешних зависимостей. Они обычно используются с mocks или заглушками.
• Тесты интеграции включают несколько компонентов и могут полагаться на внешние зависимости.

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

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

Ответ 12

Интеграционные тесты позволяют проверить работоспособность всех приложений вашего приложения.

Модульные тесты проверяют правильность логики низкого уровня в приложении.

Интеграционные тесты более полезны для менеджеров, чтобы чувствовать себя более уверенно в состоянии проекта (но полезно для разработчиков тоже!).

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

И, конечно же, используйте их для достижения наилучших результатов.

Ответ 13

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

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

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

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

Ответ 14

Как я вижу интеграционное тестирование модульное тестирование:

Модульное тестирование: тестируйте мелкие предметы изолированно с деталями низкого уровня, включая, помимо прочего, "условия метода", проверки, циклы, дефолты, вычисления и т.д.

Интеграционное тестирование: тестируйте более широкий охват, включающий в себя несколько компонентов, которые могут влиять на поведение других вещей, когда они вместе. Интеграционные тесты должны охватывать сквозную интеграцию & поведения. Цель интеграционных тестов должна состоять в том, чтобы доказать, что системы/компоненты работают нормально при интеграции вместе