В чем разница между интеграционным и модульным тестами?

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

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

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

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

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

Ответов (20)

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

На мой взгляд, ответ - "Почему это важно?"

Это потому, что юнит-тесты - это то, что вы делаете, а интеграционные тесты - это то, чего вы не делаете? Или наоборот? Конечно, нет, вы должны попробовать сделать и то, и другое.

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

Это потому, что вы используете mocks в модульных тестах, но не используете их в интеграционных тестах? Конечно, нет. Это будет означать, что если у меня есть полезный интеграционный тест, мне не разрешено добавлять макет для какой-то части, опасаясь, что мне придется переименовать свой тест в «модульный тест» или передать его другому программисту для работы.

Причина в том, что модульные тесты тестируют один модуль, а интеграционные тесты тестируют несколько модулей? Конечно, нет. Какое это практическое значение? Теоретическое обсуждение объема тестов в любом случае не работает на практике, потому что термин «единица» полностью зависит от контекста. На уровне класса единицей может быть метод. На уровне сборки юнит может быть классом, а на уровне обслуживания юнит может быть компонентом. И даже классы используют другие классы, так что это за единица?

Это не имеет значения.

Тестирование важно, важно ПЕРВОЕ, разбрасываться по определениям - пустая трата времени, которая только сбивает с толку новичков в тестировании.

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

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

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

Скажем, у вас есть такой метод:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  Log.TrackTheFactYouDidYourJob();
  return someResults;
}

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

Feature: To be able to do something
  In order to do something
  As someone
  I want the system to do this thing

Scenario: A sample one
  Given this situation
  When I do something
  Then what I get is what I was expecting for

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

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

На практике вы делаете что-то вроде:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
  return someResults;
}

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

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

Функция не будет работать, потому что Log сломана, а не потому, что [Do your job with someInput] не выполняет свою работу. И, кстати, [Do your job with someInput] это единственная ответственность за этот метод.

Кроме того, предположим, что Log он используется в 100 других функциях, в 100 других методах 100 других классов.

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

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

Тем не менее, DoSomething юнит-тест имеет зеленый цвет, потому что он использует подделку Log, созданную , чтобы никогда не ломаться. И да: это явно вранье . Он сообщает, что неработающая функция работает. Чем это может быть полезно?

(Если DoSomething() модульный тест не [Do your job with someInput] прошел , убедитесь: в нем есть ошибки.)

Предположим, это система с неработающим классом: Система с неработающим классом

Одна ошибка нарушит работу нескольких функций, а несколько интеграционных тестов не пройдут.

Одна ошибка нарушит работу нескольких функций, а несколько интеграционных тестов не пройдут.

С другой стороны, та же ошибка нарушит только один модульный тест.

Эта же ошибка нарушит только один модульный тест

Теперь сравните два сценария.

Эта же ошибка нарушит работу только одного модульного теста.

  • Все ваши функции, использующие сломанный Log, красные
  • Все ваши модульные тесты зеленые, только модульный тест Logкрасный

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

Различия

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

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

Вот почему я думаю, что ваше предложение «Или это просто модульный тест, охватывающий 2 класса» как-то смещено. Модульный тест никогда не должен охватывать 2 класса.

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

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

Характер ваших тестов

Тестовый модуль модуля X представляет собой тест , который ожидает (и проверяет) проблемы только в модуле X.

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

Подумайте о природе ваших тестов в следующих терминах:

  • Снижение риска : для этого нужны тесты. Только сочетание модульных тестов и интеграционных тестов может дать вам полное снижение риска, потому что, с одной стороны, модульные тесты по своей сути не могут тестировать правильное взаимодействие между модулями, а с другой стороны, интеграционные тесты могут использовать функциональность только нетривиального модуля. в небольшой степени.
  • Усилия по написанию тестов : интеграционные тесты могут сэкономить усилия, потому что тогда вам может не понадобиться писать заглушки / фейки / макеты. Но модульные тесты также могут сэкономить усилия, поскольку реализация (и поддержка!) Этих заглушек / фейков / имитаций оказывается проще, чем настройка тестовой установки без них.
  • Задержка выполнения теста : интеграционные тесты, включающие тяжелые операции (такие как доступ к внешним системам, таким как БД или удаленные серверы), как правило, медленны (э-э). Это означает, что модульные тесты могут выполняться гораздо чаще, что снижает усилия по отладке, если что-то не удается, потому что вы лучше понимаете, что вы изменили за это время. Это становится особенно важным, если вы используете разработку через тестирование (TDD).
  • Усилия по отладке : если интеграционный тест не проходит, но ни один из модульных тестов не проходит, это может быть очень неудобно, поскольку задействовано слишком много кода, который может содержать проблему. Это не большая проблема, если вы ранее изменили только несколько строк, но поскольку интеграционные тесты выполняются медленно, возможно, вы не запускали их в такие короткие промежутки времени ...

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

Прагматичный подход к использованию обоих

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

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

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

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

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

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

Единичные тесты

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

Пример: давайте подробнее рассмотрим этот момент на примере:

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

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

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

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

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

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

В модульном тесте вы тестируете каждую изолированную часть: введите описание изображения здесь

в интеграционном тесте вы тестируете многие модули своей системы:

введите описание изображения здесь

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

введите описание изображения здесь

Источники: source1 source2

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

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

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

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

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

используя дизайн единой ответственности, его черный и белый. Более 1 ответственности, это интеграционный тест.

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

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

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

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

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

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

Мои 10 бит: D

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

Интеграционные тесты - это следующий шаг, в котором берется один или несколько компонентов и проверяется , как они работают вместе, как должны. Теперь вы больше не беспокоитесь о том, как компоненты работают по отдельности, но когда вы вводите html в свой HtmlEditControl , он каким-то волшебным образом знает, действителен он или нет ..

Хотя это настоящая подвижная линия ... Я бы предпочел больше сосредоточиться на том, чтобы чертов код работал полностью ^ _ ^

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

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

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

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

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

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

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

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

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

Я называю модульными тестами те тесты, которые тестируют методом белого ящика. Любые зависимости, которые требует класс, заменяются фальшивыми (моковыми).

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

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

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

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

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

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

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

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

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

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

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

Модульные тесты используют макеты

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