Модульное тестирование на больших базах данных

Question

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

Я хочу написать модульные тесты для приложения, которое в основном реализовано на T-SQL, так что имитация базы данных не вариант. База данных довольно большая (около 10 ГБ), поэтому восстановление базы данных после пробного запуска также практически невозможно.

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

Я рассматриваю два подхода:

Первый подход

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

преимущества

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

Недостатки

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

---

Второй подход

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

преимущества

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

Недостатки

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

---

Что вы думаете об этих двух подходах?

Кто-нибудь из читателей Stack Overflow считает, что стоит создать объекты, как описано во втором подходе?

У кого-нибудь здесь есть опыт создания таких тестов?

Answer 1

Я не уверен, что полностью согласен с вашим предположением, что вы не сможете восстановить базу данных после пробного запуска. Хотя я определенно согласен с тем, что некоторые тесты следует запускать для полноразмерной базы данных с несколькими туберкулезами, я не понимаю, почему вы не можете выполнить большинство своих тестов на базе данных с гораздо меньшими размерами. Существуют ли ограничения, которые необходимо проверить, например: «Не может быть более миллиарда одинаковых строк?»

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

Answer 2

Для создания данных приборов для тестов у вас есть несколько вариантов:

(a) Создайте сценарий, который создает пустую базу данных, а затем добавляет небольшое количество записей в качестве данных фикстуры. Эти данные могут быть построены вручную, или несколько записей из реальной базы данных. Это подход Rails, довольно распространенный в мире Java.

(b) Для создания этих данных также часто используется «фабрика» (своего рода код приложения). Первоначальные инвестиции в создание этих классов существуют, но после их создания они могут быть повторно использованы для всех ваших тестов. Это сейчас очень популярно в Ruby / Rails-коде. (Это ваш второй подход выше.)

(c) Конечно, вы можете использовать копию «производственных» данных и попытаться проверить это. Но это, вероятно, самый сложный подход, так как вы всегда будете бороться с реальным миром, меняющим данные. И это также, как правило, на несколько порядков медленнее, чем небольшой набор данных о приборах.

Определенно, стоимость перехода из состояния (c) в состояние (a) или (b) определена, но это инвестиции в будущее. Это не займет много времени - даже если это займет целый день, ускорение в тестовом прогоне компенсирует это быстро.

У кого-то есть независимая проблема. После того, как вы поместите свои данные в базу данных, а затем запустите свои тесты, вам необходимо восстановить их. Есть несколько общих подходов:

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

(2) просто перезагрузите новый набор данных прибора. Если данные вашего прибора небольшие, это выполнимо. Немного медленнее, чем (1).

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

Рекомендация

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

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

Answer 3

Как насчет тестирования всего в транзакции и ее отката? Например:

BeginTransaction
DoThings
VerifyResult
RollbackTransaction