Непрерывная Интеграция: хранение теста актуальная схема DB

Что мы нашли, поскольку самый управляемый способ справиться с постепенной эволюцией живет/тестирует, Схемы DB используют инструмент управления миграции схемы как Liquibase

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

Что я делаю в своих тестах:

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

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

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

Я использую migrateDB для управления этой проблемой.

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

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

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

Это работает вполне хорошо на нас.

Вот что мы делаем:

$ find src/sql/ | grep -v /.svn
src/sql/
src/sql/0000-system.sql
src/sql/0000-system.sql.dev.log
src/sql/0000-system.sql.prod.log
src/sql/0000-system.sql.test.log
src/sql/0001-usgn.sql
src/sql/0001-usgn.sql.dev.log
src/sql/0001-usgn.sql.prod.log
src/sql/0001-usgn.sql.test.log
src/sql/0002-usgn.sql
src/sql/0002-usgn.sql.dev.log
src/sql/0002-usgn.sql.prod.log
src/sql/0002-usgn.sql.test.log
src/sql/0003-usgn.sql
src/sql/0003-usgn.sql.dev.log
src/sql/0003-usgn.sql.prod.log
src/sql/0003-usgn.sql.test.log
src/sql/0004-system.sql
src/sql/0004-system.sql.dev.log
src/sql/0005-usgn.sql
src/sql/purge.sql

у нас есть scriptseq ### - databaseusercredential.sql

Теперь наши тесты всегда учитывают неизвестное начальное состояние данных в БД. Если вы не можете этого сделать, то я бы предложил вам использовать SEQ-CRED-TYPE.sql, где type будет dml / ddl, и отфильтровать сценарии dml.

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

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

Был бы, добавляя sql сценарий к Вашему набору тестов, который удаляет все данные в работе базы данных для Вас?

Таким образом, процесс был бы:

1. выполненная миграция дб.
2. запустите скрипт для удаления всех данных в дб.
3. данные нагрузочного теста
4. запустите тесты

Предыдущий постер перечислил Liquibase в качестве опции, однако не упомянул способность Liquibase определять правила, которые выполняются в определенных контекстах ( Контексты в Liquibase ). Это позволяет вам иметь обновления схемы, не помеченные каким-либо конкретным контекстом, а фикстуры для модульных тестов помечены как контекст test . Таким образом, фикстуры будут вставлены только при выполнении ваших модульных тестов.

Вот пример набора изменений Liquibase, который содержит схему и фикстуры:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.9" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.9 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.9.xsd">
  <changeSet author="avalade" id="1">
    <createTable tableName="users">
      <column autoIncrement="true" name="id" type="long">
        <constraints nullable="false" primaryKey="true" />
      </column>
      <column name="email" type="varchar(255)" />
    </createTable>
  </changeSet>
  <changeSet author="avalade" id="2" context="test">
    <insert tableName="user">
      <column name="id" value="1" />
      <column name="email" value="test@test.com" />
    </insert>
  </changeSet>
</databaseChangeLog>

Затем, если вы используете Spring для управления своими DAO, вы можете поместить следующее в развертываемый вами файл контекста приложения:

<bean id="liquibase" class="liquibase.spring.SpringLiquibase">
  <property name="dataSource" ref="dataSource" />
  <property name="changeLog" value="classpath:dbChangelog.xml" />
</bean>

Для файла контекста приложения, который вы используете в своих модульных тестах, настройте Liquibase с дополнительным свойством контекста:

<bean id="liquibase" class="liquibase.spring.SpringLiquibase">
  <property name="dataSource" ref="dataSource" />
  <property name="changeLog" value="classpath:dbChangelog.xml" />
  <property name="contexts" value="test" />
</bean>

Таким образом,