Я юнит тестирование или интеграционное тестирование?

Question

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

Это то, что должно быть сделано в модульном тесте или интеграционном тесте?

Спасибо

Answer 1

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

Обычно я предпочитаю тестировать что-то подобное, высмеивая компонент, который "метод доступа к данным" использовал для получения реальных данных, будь то соединение JDBC, прокси веб-службы или что-то еще. При использовании mock вы говорите: «когда вызывается этот метод, верните его» или «убедитесь, что этот метод вызывается N раз», а затем говорите тестируемому классу использовать компонент mock, а не реальный компонент. Тогда это «модульный тест», потому что вы тестируете, как ведет себя тестируемый класс, в закрытой системе, где вы точно объявили, как будут вести себя другие компоненты. Вы полностью изолировали тестируемый класс и можете быть уверены, что результаты вашего теста не будут нестабильными и зависят от состояния другого компонента.

Не уверен, с каким языком / технологией вы работаете, но в мире Java вы можете использовать JMock, EasyMock и т. Д. Для этой цели.

Answer 2

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

Мне все равно.

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

Например, я, вероятно, начну подключаться к реальной тестовой БД на своей работе. Но если программное обеспечение должно работать со многими различными базами данных - Oracle, PostGres, MySQL, SQL-сервером и БД, или если тестируемая БД на работе не работает из-за «обновлений», я бы, вероятно, написал «pure / unit» тест, который существовал полностью в изоляции.

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

Я твердо верю в это; Я представил перед Google на это.

http://www.google.com/url?sa=t&source=web&oi=video_result&ct=res&cd=1&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DPHtEkkKXSiY&ei=9-wKSobjEpKANvHT_MEB&rct=j&q=heusser+GTAC+2007&usg=AFQjCNHOgFzsoVss50Qku1p011J4-UjhgQ

удачи! Дайте нам знать, как это происходит!

Answer 3

Пройдите тест и позвольте другим людям проводить время с таксономией

Answer 4

Моя точка зрения заключается в том, что вы должны классифицировать тест на основе области:

• A модульный тест может быть запущен автономно без каких-либо внешних зависимостей (Файл IO, сетевой IO, база данных, Внешние веб-сервисы).
• интеграционный тест может касаться внешних систем.

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

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

Если внешнюю зависимость сложно смоделировать (например, в DotNet, если вы используете Rhino Mocks и внешние классы не имеют интерфейсов), то создайте тонкий класс-оболочку, который касается внешней системы. Затем смоделируйте эту обертку в модульных тестах. Вам не нужна база данных для запуска этого простого теста, поэтому не требуйте ее!

Answer 5

Есть те (включая меня), у которых есть строгие правила о том, что составляет юнит-тест против интеграционного теста.

Тест не является модульным тестом , если:

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

Что может быть одним из способов провести различие между тем, что будет делать для вас модульный тест, например, с помощью насмешек, а не с какими-либо реальными поставщиками ресурсов - файловой системой, БД и т. Д.

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

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

Answer 6

Я думаю, что важный вопрос: «Что СЛЕДУЕТ делать?»

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

Определенно модульный тест это!

[TestMethod]
public void ForgotMyPassword_SendsAnEmail_WhenValidUserIsPassed()
{
    var userRepository = MockRepository.GenerateStub<IUserRepository>();
    var notificationSender = MockRepository.GenerateStub<INotificationSender>();
    userRepository.Stub(x => x.GetUserByEmailAddressAndPassword("me@home.com", "secret")).Return(new User { Id = 5, Name = "Peter Morris" });

    new LoginController(userRepository, notificationSender).ResendPassword("me@home.com", "secret");

    notificationSender.AssertWasCalled(x => x.Send(null),
        options => options.Constraints(Text.StartsWith("Changed")));
}

Answer 7

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

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

Answer 8

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

Answer 9

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

Я могу ошибаться, но я так думаю, если кто-то не даст мне повода думать иначе.

Answer 10

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