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

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

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

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

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

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

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

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

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

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

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

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

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

Мои 10 битов: D

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не важно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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