Каково различие между интеграцией и модульными тестами? [закрытый]

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

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

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

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

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

294
задан TylerH 9 September 2019 в 06:05
поделиться

11 ответов

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

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

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

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

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

1
ответ дан Pavel Feldman 23 November 2019 в 01:36
поделиться

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

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

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

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

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

2
ответ дан CVertex 23 November 2019 в 01:36
поделиться

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

1
ответ дан John Smithers 23 November 2019 в 01:36
поделиться

Поблочное тестирование является методом тестирования, которое проверяет, что отдельные единицы исходного кода работают правильно.

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

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

4
ответ дан grom 23 November 2019 в 01:36
поделиться

Поблочное тестирование тестирует против единицы работы или блока кода, если Вам нравится. Обычно выполняемый единственным разработчиком.

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

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

3
ответ дан Christian Hagelid 23 November 2019 в 01:36
поделиться

с помощью Единственного дизайна ответственности, его черного цвета и белого цвета. Больше чем 1 ответственность, интеграционный тест.

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

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

12
ответ дан DevelopingChris 23 November 2019 в 01:36
поделиться

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

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

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

4
ответ дан Lance Fisher 23 November 2019 в 01:36
поделиться

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

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

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

17
ответ дан Jon Limjap 23 November 2019 в 01:36
поделиться

Мои 10 битов: D

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

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

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

43
ответ дан Rob Cooper 23 November 2019 в 01:36
поделиться

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

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

62
ответ дан ShellZero 23 November 2019 в 01:36
поделиться

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

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

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

4
ответ дан Michael Neale 23 November 2019 в 01:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: