В чем разница между интеграцией и юнит-тестами?

Question

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

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

Действительно ли эти тесты стали интеграционными, потому что теперь они тестируют интеграцию этих 2 классов, или это просто модульный тест, охватывающий 2 класса?

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

Я неправильно понимаю интеграционные тесты, или на самом деле разница между интеграцией и модульными тестами очень мала?

---

Редактировать

Спасибо всем за отличные ответы! Я думаю, что из разных ответов ясно, что грань между юнит-тестами и интеграционными тестами определенно размыта, и, возможно, немного педантично пытаться выяснить, какие из них и на чем стоит сосредоточиться (спасибо @Rob Cooper ). Кроме того, извините, но я не собираюсь принимать какой-либо ответ, потому что слишком многие слишком хороши, и это действительно кажется весьма субъективным.

Answer 1

Модульное тестирование - это метод тестирования, который проверяет правильность работы отдельных блоков исходного кода.

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

Википедия определяет единицу как наименьшую тестируемую часть приложения, которая в Java / C # является методом. Но в вашем примере с классами Word и Sentence я, вероятно, просто напишу тесты для предложения, так как я, вероятно, сочту излишним использование класса слов mock для тестирования класса предложений. Таким образом, предложение будет моей единицей, а слово - деталью реализации этой единицы.

Answer 2

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

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

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

Answer 3

Модульное тестирование - это тестирование на единицу работы или блок кода, если хотите. Обычно выполняется одним разработчиком.

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

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

Answer 4

Простое объяснение с аналогами

Приведенные выше примеры очень хороши, и мне не нужно их повторять. Поэтому я сосредоточусь на использовании примеров, чтобы помочь вам понять.

Интеграционные тесты

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

Все, что он говорит вам, это то, работает ли общая часть. Если это не помогает: он не говорит вам точно, где это происходит.

Модульные тесты

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

Пример: Давайте уточним этот момент на примере:

• Давайте возьмем машину в качестве примера.
• Интеграция тест для автомобиля: например, машина едет в Woop Woop и обратно? Если это произойдет, вы можете с уверенностью сказать, что автомобиль работает с общей точки зрения. Это интеграционный тест. Если он выходит из строя, вы не представляете, где он действительно выходит из строя: это радиатор, трансмиссия, двигатель или карбюратор? У тебя нет идей. Это может быть что угодно.
• Юнит-тест для автомобиля: работает ли двигатель? Это тестирование предполагает, что все остальное в машине работает просто отлично. Таким образом, если этот конкретный модульный тест не пройден: вы можете быть уверены, что проблема заключается в двигателе, поэтому вы можете быстро изолировать и устранить проблему.

Использование заглушек

• Предположим, ваш автомобильный интеграционный тест не прошел. Он не едет успешно в Эчуку. Где проблема?

• Теперь давайте предположим, что в вашем двигателе используется специальная система впрыска топлива и что этот тест двигателя также не прошел. Другими словами, как тест на интеграцию, так и тест двигателя не прошли. Где тогда проблема? (Дайте себе 10 секунд, чтобы получить ответ.)

• Проблема с двигателем или системой впрыска топлива?

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

Answer 5

Я называю юнит-тесты теми тестами, которые белый ящик проверяет классом. Любые зависимости, которые требуются классу, заменяются на поддельные (ложные).

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

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

Разделение двух типов тестов полезно для тестирования системы на разных уровнях. Кроме того, интеграционные тесты, как правило, долговечны, а модульные тесты должны быть быстрыми. Различие в скорости выполнения означает, что они выполняются по-разному. В наших процессах разработки модульные тесты запускаются при регистрации (это хорошо, потому что они очень быстрые), а интеграционные тесты запускаются один / два раза в день. Я стараюсь запускать интеграционные тесты как можно чаще, но, как правило, попадание в базу данных / запись в файлы / замедление работы rpc's / etc.

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

Answer 6

Кроме того, важно помнить, что как модульные, так и интеграционные тесты могут быть автоматизированы и написаны с использованием, например, JUnit. В интеграционных тестах JUnit можно использовать класс org.junit.Assume для проверки доступности элементов среды (например, соединение с базой данных) или других условий.

Answer 7

Действительно ли эти тесты стали интеграционными, потому что теперь они тестируют интеграцию этих 2 классов? Или это всего лишь юнит-тест, охватывающий 2 класса?

Я думаю Да и Да. Ваш юнит-тест, охватывающий 2 класса, стал интеграционным тестом.

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

Пример реальной разницы может быть следующим 1) Массив из 1 000 000 элементов легко тестируется модулем и работает нормально. 2) BubbleSort легко тестируется модульным массивом из 10 элементов, а также отлично работает 3) Интеграционное тестирование показывает, что что-то не так хорошо.

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

Answer 8

Немного академический вопрос, не правда ли? ;-) Моя точка зрения: Для меня интеграционный тест - это тест всей части, если не две части из десяти собираются вместе. Наш интеграционный тест показывает, будет ли успешной основная сборка (содержащая 40 проектов). Для проектов у нас есть тонны юнит-тестов. Самое важное для модульных тестов для меня состоит в том, что один модульный тест не должен зависеть от другого модульного теста. Так что для меня оба теста, которые вы описываете выше, являются модульными тестами, если они независимы. Для интеграционных тестов это не должно быть важным.

Answer 9

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

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