Поблочное тестирование против больших баз данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BeginTransaction
DoThings
VerifyResult
RollbackTransaction