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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интеграционные тесты часто находят то, чего нет в модульных тестах ...

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

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

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

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

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

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

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

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

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

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

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

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

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