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

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

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

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

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

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

14.08.2008 06:27:57
20 ОТВЕТОВ

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

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

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

12
14.08.2008 06:36:29

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

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

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

17
14.08.2008 06:34:05
«Технически вы все равно не можете выполнить модульное тестирование только одним классом. Что если ваш класс составлен из нескольких других классов?» Что ж, «строгий» модульный тест просто смоделирует / заглушит все зависимости. Тем не менее, это спорно ли это всегда практично ...
sleske 3.10.2010 16:12:53
Это правда. Важным моментом является способность сохранять зависимости до абсолютного минимума.
Jon Limjap 4.10.2010 09:58:20
-1, модульный тест проверяет не одну функцию, а одну программную функцию или класс, т. Е. Тестирует логическую единицу программного обеспечения.
CharlesB 17.09.2013 17:41:10

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

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

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

3
14.08.2008 06:36:58

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

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

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

4
14.08.2008 06:37:17

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

1
14.08.2008 06:37:59

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

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

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

4
14.08.2008 06:47:54

Мои 10 битов: D

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

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

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

43
14.08.2008 08:59:28

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

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

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

4
14.08.2008 10:26:18

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

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

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

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

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

2
14.08.2008 12:19:55

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

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

62
16.04.2018 20:15:33

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

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

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

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

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

1
25.09.2008 09:37:29

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

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

23
20.04.2012 08:06:11
Я знаю, что это старый пост, но я только что наткнулся на него. Что, если у вас был третий класс с именем Font, с которым взаимодействует класс Sentence, и вы хотите проверить функциональность между Word и классом Sentence, то вам пришлось бы смоделировать класс Font, но это не сделает его модульным тестом. Итак, я говорю, что использование mocks не обязательно делает его модульным тестом, mocks также можно использовать в интеграционных тестах.
n.Stenvang 11.12.2014 13:53:55
Конечно, макеты могут использоваться в интеграционных тестах, но для того, чтобы модульный тест действительно был таким, все модели, внешние по отношению к модулю, должны быть смоделированы . Если интеграционные тесты используют макеты, то, скорее всего, они являются частичными интеграционными тестами (если такой термин существует). Конечно, это частичные интеграционные тесты, которые являются нисходящими или восходящими. Последние обычно не требуют издевательств, в то время как прежние делают.
Robert Koritnik 11.12.2014 22:01:10

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

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

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

Скажем, у вас есть метод где-то вроде этого:

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;
}

Вы можете сделать это с помощью Dependency Injection, с помощью некоторого Factory Method или любой 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 класса.

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

297
10.05.2018 12:07:34
Действительно хороший ответ! Однако я просто хочу добавить, что издевательство не только для юнит-теста. Это также может быть очень полезно во многих интеграционных тестах.
n.Stenvang 11.12.2014 13:19:58
Отличный ответ! Я просто не совсем согласен с двумя моментами: 1) что интеграционные тесты «бесполезны при угадывании, где может быть проблема»; и 2) что «модульный тест никогда не должен охватывать 2 класса». Я создал множество интеграционных тестов, и когда они ломаются, обычно нетрудно точно определить источник проблемы, если вы получаете полную трассировку стека или одно неудачное утверждение (в этом случае найти источник может быть сложнее, но не так много, так как интеграционный тест предоставляет контекст для отладки). (продолжение)
Rogério 22.04.2015 21:53:43
Модульные тесты могут выполнять несколько классов при условии, что они не являются публичными классами, которые должны иметь свои собственные отдельные модульные тесты. Один случай - когда открытый тестируемый класс использует другие закрытые вспомогательные классы, которые существуют только для поддержки открытого класса; в этом случае «единица» содержит два или более классов. Другой случай заключается в том, что большинство классов используют сторонние классы (класс String / string, классы коллекций и т. Д.), Которые не имеют смысла для насмешек или изоляции; мы просто рассматриваем их как стабильные и надежные зависимости, выходящие за рамки тестирования.
Rogério 22.04.2015 21:58:37
С помощью интеграционных тестов немного сложнее найти корневую проблему, но вы все равно можете ее отладить и найти корневую проблему. Если предположить, что модульные тесты выполняются не часто, то, возможно, редко исправление ошибок занимает немного больше времени, если у вас есть только интеграционные тесты, но тогда вы получаете дополнительную ценность интеграции компонентов тестирования и экономите время написания модульные тесты. Я думаю, что это утверждение (которое пришло от моего босса) неверно, но я не уверен, как я могу убедить его, какие-либо идеи?
BornToCode 11.08.2015 15:20:21
Исходя из рассуждений в этом ответе, можно утверждать, что было бы более эффективно пропускать написание модульных тестов и тратить сэкономленное время, обнаруживая источник неудачных интеграционных тестов, когда они терпят неудачу.
user74754 29.08.2016 22:47:52

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

4
18.07.2012 17:01:22

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

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

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

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

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

Это не важно.

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

8
28.08.2015 20:04:28
-1 Определение - это то, что делает людей способными использовать одни и те же термины, не всегда объясняя, что они означают, и важно для сотрудничества. Поэтому важно понимать разницу между этими двумя понятиями.
CharlesB 22.07.2013 08:48:57
Как упомянул @CharlesB, это важно, поэтому нет необходимости каждый раз объяснять или обнаруживать, что у каждого свое определение, вызывающее путаницу. Тесты будут написаны по-разному и будут проходить по-разному, но это не означает, что не следует делать и то, и другое, чтобы определить различия.
Shane 17.10.2017 18:41:36
Вывод ответа может быть экстремальным, но большинство его положений вполне верны: модульные тесты и интеграционные тесты - это, в основном, одно и то же, за исключением их гранулярности, и неясно, где должна быть проведена граница между ними.
Lutz Prechelt 19.03.2018 12:54:44
Это не помогает при создании общего языка в профессиональной среде. Хотя, в основном, вы правы, это не имеет большого значения, отсутствие общего языка вызовет недопонимание и замешательство в команде. Я думаю, что лучший вариант состоит в том, чтобы команда согласовала свои термины и определения.
user924272 12.02.2019 18:47:23

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

1
10.09.2013 17:12:33

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

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

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

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

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

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

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

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

10
25.02.2019 15:27:14

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

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

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

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

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

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

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

Пример: давайте подробно остановимся на этом, используя пример:

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

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

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

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

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

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

2
25.02.2019 16:15:11

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

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

0
2.11.2018 17:08:54

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

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

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

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

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

Источники: источник1 источник2

7
31.07.2019 05:28:36
У вас есть три изображения, но только два источника.
gerrit 5.12.2019 16:47:25
@gerrit взглянуть на первый источник - две картинки оттуда
Michu93 6.12.2019 08:04:28
Люблю этот ответ
Dzenis H. 2.04.2020 19:06:32