Создание структуры базы данных в памяти из экземпляра Oracle

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

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

поэтому моя идея состоит в том, чтобы постепенно заменить этот тестовый экземпляр Oracle базой данных в памяти. Я буду использовать hsqldb или лучше h2.

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

конечно, я могу извлечь структуру базы данных из Oracle, использование некоторых инструментов, таких как SQL Developer или TOAD, а затем изменение этих скриптов, чтобы адаптировать их к hsqldb или h2 язык. Но я не думаю, что это лучший подход.


на самом деле, я уже сделал это в другом проекте, используя hsqldb, но я написал вручную все скрипты для создания таблиц. К счастью, у меня было всего несколько таблиц для создания. Моей главной проблемой на этом этапе было "перевести" скрипты Oracle, используемые для создания таблиц в hsqldb язык.

например, таблица, созданная в Oracle с помощью следующей команды sql:

CREATE TABLE FOOBAR (
    SOME_ID NUMBER,
    SOME_DATE DATE, -- Add primary key constraint
    SOME_STATUS NUMBER,
    SOME_FLAG NUMBER(1) DEFAULT 0 NOT NULL);

необходимо было "перевести" для hsqldb в:

CREATE TABLE FOOBAR (
    SOME_ID NUMERIC,
    SOME_DATE TIMESTAMP PRIMARY KEY,
    SOME_STATUS NUMERIC,
    SOME_FLAG INTEGER DEFAULT 0 NOT NULL);

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


Итак, мои вопросы:

  • какие советы вы можете дать мне добиться этого?
  • тут h2 или hsqldb предоставить некоторые инструменты для создания их скрипты из соединения Oracle?

техническая информация

Java 1.6, Spring 2.5, Oracle 10.g, Maven 2


редактировать

некоторая информация о моих модульных тестах:

в приложении, где я использовал hsqldb, у меня были следующие испытания: - Некоторые" базовые " модульные тесты, которые не имеют ничего общего с БД. - Для тестирования DAO я использовал hsqldb для выполнения базы данных манипуляции, такие как CRUD. - Тогда, на уровне сервиса, я использовал Mockito чтобы издеваться над моими объектами DAO, чтобы сосредоточиться на тесте службы, а не на всех приложениях (т. е. service + dao + DB).

в моем текущем приложении у нас есть худший сценарий: тесты уровня DAO нуждаются в подключении Oracle для запуска. Слой услуги не используйте (пока) любые макетные объекты для имитации DAO. Так что услуги тестов и нужен Оракул соединение.

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

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

4 ответов


используйте базу данных in-memory / Java для тестирования. Это гарантирует, что тесты ближе к реальному миру, чем если вы попытаетесь "абстрагировать" базу данных в своем тесте. Вероятно, такие тесты также легче писать и поддерживать. С другой стороны, то, что вы, вероятно, хотите "абстрагироваться" в своих тестах, - это пользовательский интерфейс, потому что тестирование пользовательского интерфейса обычно трудно автоматизировать.

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

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

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


последняя версия HSQLDB 2.0.1 поддерживает синтаксис ORACLE для DUAL, ROWNUM, NEXTVAL и CURRVAL с помощью флага совместимости синтаксиса sql.syntax_ora=true. Таким же образом конкатенация строки с нулевой строкой и ограничения на NULL в уникальных ограничениях обрабатываются другими флагами. Большинство функций ORACLE, таких как TO_CHAR, TO_DATE, NVL и т. д. уже встроены.

на данный момент, чтобы использовать простые типы ORACLE, такие как NUMBER, вы можете использовать определение типа:

создать ВВЕДИТЕ ЧИСЛО КАК NUMERIC

следующий снимок позволит NUMBER (N) и другие аспекты совместимости типов ORACLE, когда установлен флаг.

загрузить из http://hsqldb.org/support/

[Update:] снимок, выпущенный 4 октября, преобразует большинство типов Oracle в типы ANSI SQL. HSQLDB 2.0 также поддерживает тип интервала ANSI SQL и арифметику даты / метки времени так же, как Oracle.


для чего нужны модульные тесты? Если они проверяют правильную работу DDLs и хранимых процедур, то вы должны написать тесты "ближе" к Oracle: либо без Java-кода, либо без Spring и других хороших веб-интерфейсов вообще с акцентом на БД.

Если вы хотите протестировать логику приложения, реализованную в Java и Spring, вы можете использовать mock objects / database connection, чтобы сделать ваши тесты независимыми от базы данных.

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


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

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