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

Скажем, у меня есть две таблицы в базе данных, одна называется students, а другая - departments. students выглядит следующим образом:

department_id, student_id, class, name, age, gender, rank

и departments выглядит следующим образом:

department_id, department_name, campus_id, number_of_faculty

У меня есть API, который может запрашивать базу данных и извлекать различную информацию из двух таблиц. Например, у меня есть конечная точка, которая может получить количество студентов в каждом кампусе, объединив 2 таблицы.

Я хочу выполнить интеграционное тестирование для конечных точек API. Для этого я создаю локальную базу данных, запускаю миграцию схем базы данных для создания таблиц, а затем заполняю каждую таблицу искусственными записями, чтобы точно знать, что находится в базе данных. Но приход с хорошим процессом посева оказался чем-то легким. Для простого примера, описанного выше, мой текущий подход включает в себя создание нескольких разных записей для каждого столбца. Например, мне нужно как минимум 2 студенческих городка (скажем main и satellite) и 3 отдела (скажем Electrical Engineering и Mathematics для кампуса main и English для кампуса satellite). Тогда мне нужно как минимум 2 студента в каждом отделе или всего 6 студентов. И если я смешиваю в gender, age и rank, вы можете легко увидеть, что количество искусственных записей растет экспоненциально. Придумывание всех этих искусственных записей является ручным и, следовательно, утомительным для поддержания.

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

Ответы

Ответ 1

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

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

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

Однако это может быть неприемлемо по следующим причинам:

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

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

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

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

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

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

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

При отсутствии готового инструмента вы можете применить следующие шаги:

  • начать с простого генератора комбинаторных данных
  • применять некоторые ограничения, устраняя бесполезные или незаконные записи

  • запускать тесты, фиксируя данные о покрытии, добавлять дополнительные записи данных для улучшения повторного тестирования покрытия до тех пор, пока покрытие не будет ОК

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

Ответ 2

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

Ответ 3

Если вам нужно инициализировать базу данных таблицами и фиктивными данными с помощью Junit,

Я использую Unitils или DbUnit

Данные в Unitils могут быть загружены из файлов XML внутри вашей папки ресурсов, поэтому, как только запускается тестовый бегун, он загрузит весь контент из xml и вставляет его в базу данных, пожалуйста, посмотрите примеры на своем веб-сайте.