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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мои 10 битов: D

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

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