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

Question

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

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

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

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

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

---

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

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

Answer 1

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

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

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

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

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 класса.

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

Мои 10 битов:D

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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

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

Это не важно.

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

Answer 10

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

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

Answer 11

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

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

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

Answer 12

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

Answer 13

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

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

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

Answer 14

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

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

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

Answer 15

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

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

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

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

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

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

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

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

Последствия смешивания вашей интеграции и юнит-тестов:

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

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

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

Надеюсь, это поможет.

Answer 16

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

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

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

Answer 17

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

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

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

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

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

Answer 18

Меня часто спрашивают об этом в интервью. До сих пор я претенциозно болтал о своем опыте и разглагольствовал о компонентном и приемочном тестировании.

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

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

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

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

Вот иерархия тестов, от дешевых и обильных внизу до медленных, дорогих и малочисленных вверху:

Можно концептуализировать еще несколько слоев, но они были опущены для ясности.

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

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

Они будут запускаться не локально, а на сервере сборки. Сочетание локальных Jenkins и облачных CI-провайдеров удовлетворяет эту потребность.

Другая тестовая терминология

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

Приемочные испытания были тем, что мы бы назвали требованиями бизнес-подразделения или клиента. Они будут определять направление всего и сидеть на вершине пирамиды (представьте себе знак доллара).

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

Answer 19

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

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

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

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

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

Answer 20

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

Answer 21

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

Answer 22

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

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