Данные базы данных необходимы в интеграционных тестах; созданный вызовами API или использованием импортированных данных?

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

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

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

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

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

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

, Очевидно, эти тесты были путь медленнее , чем чистые модульные тесты.

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

, Почему эти два подхода определяются как являющийся исключительно?

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

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

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

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

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

Я делаю обоих, в зависимости от того, что я должен протестировать:

• я импортирую данные статического испытания из сценариев SQL или дампов DB. Эти данные используются в объектной загрузке (десериализация или отображение объекта) и в тестах SQL-запроса (когда я хочу знать, возвратит ли код корректный результат).

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

• , Когда у меня есть код, который изменяет DB (объект-> DB), я обычно выполняю его против живущего DB (в памяти или тестовом экземпляре куда-нибудь). Это должно гарантировать, что код работает; не создать любую большую сумму строк. После теста я откатываю транзакцию (после правила, что тесты не должны изменять глобальное состояние).

, Конечно, существуют исключения из правила:

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

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

, Когда возможный я предпочитаю использовать фактическую базу данных. Часто запросы (записанный в SQL, HQL, и т.д.) в классах CRUD могут возвратить неожиданные результаты, сталкиваясь с фактической базой данных. Лучше промыть эти проблемы вначале. Часто разработчики будут писать очень тонкие модульные тесты на CRUD; тестирование только самых мягких случаев. Используя фактическую базу данных для Вашего тестирования может протестировать все угловые случаи видов, о которых Вы не могли даже знать.

, Что быть сказанным там может быть другими проблемами. После каждого теста Вы хотите возвратить свою базу данных известному состоянию. Это мое текущее задание мы уничтожаем базу данных путем выполнения всех операторов DROP и затем полностью воссоздания всех таблиц с нуля. Это чрезвычайно медленно на Oracle, но может быть очень быстро, если Вы используете в базе данных памяти как HSQLDB. Когда мы должны спугнуть конкретные вопросы Oracle, мы просто изменяем базу данных URL и свойства драйвера и затем выполнение против Oracle. Если у Вас нет этого вида мобильности базы данных затем, Oracle также имеет некоторую функцию снимка базы данных, которая может быть использована именно с этой целью; откат всей базы данных к некоторому предыдущему состоянию. Я уверен, что имеют другие базы данных.

В зависимости от того, какие данные будут в Вашей базе данных, API или подход загрузки могут работать лучше или хуже. Когда у Вас будут очень структурированные данные со многими отношениями, API сделают Вашу жизнь easer моим созданием отношений между Вашими данными явный. Вам будет более трудно сделать ошибку при создании набора данных тестирования. Как упомянуто другим рефакторингом плакатов инструменты могут заботиться о некоторых изменениях в структуре Ваших данных автоматически. Часто я нахожу, что это полезный для размышления о API генерировало данные тестирования как создание сценария; то, когда пользователь/система сделает шаги X, Y Z и затем протестирует, пойдет оттуда. Эти состояния могут быть достигнуты, потому что можно записать программу, которая называет тот же API, который использовал бы пользователь.

Загружающиеся данные становятся намного более важными при необходимости в больших объемах данных у Вас есть немного отношений между в Ваших данных или существует непротиворечивость в данных, которых нельзя выразить с помощью API или стандартных реляционных механизмов. В одном задании, которое в обработанном в моей команде писало приложение для создания отчетов для системы проверки пакетов большой сети. Объем данных был довольно большим в течение времени. Для инициирования полезного подмножества тестовых сценариев, нам действительно были нужны данные тестирования, сгенерированные снифферами. Таким образом, корреляции между информацией об одном протоколе коррелировали бы с информацией о другом протоколе. Было трудно получить это в API.

базы данных Most имеют инструменты, чтобы импортировать и экспортировать файлы разделенного текста таблиц. Но часто Вы только хотите подмножества их; создание более сложных дампов данных использования. В моем текущем задании мы должны взять некоторые дампы фактических данных, которые сгенерированы программами Matlab и сохранили в базе данных. У нас есть инструмент, который может вывести подмножество данных базы данных и затем сравнить их с "наземной истиной" для тестирования. Кажется, что наши инструменты извлечения постоянно изменяются.

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

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

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

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

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

Это просто и очень легко повторяемо.