Модульное тестирование DDL с SQL Developer 3.1

Question

SQL Developer поддерживает модульное тестирование DML, но я не нашел способа создания модульных тестов для DDL.Что было бы хорошим подходом к этой проблеме?Схема, с которой я начинаю, маленькая, менее десятка таблиц с большими проектами на горизонте.Google не очень-то возвращается к применению модульных тестов для DDL.Любые идеи о подходе к тестированию DDL или других инструментов, которые существуют для модульного тестирования DDL?

Answer 1

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

Я сделал кое-что из этого, используя «шаблон» assert - т. Е. Tdd.ddlunit.assert_tableexists (p_schema_name, p_table_name), который вызывает исключение, если таблица не существует, и автоматически запускается, когда это происходит.

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

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

Answer 2

Что вы хотите проверить на предмет DDL?Либо таблица создается как определено, либо нет.

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

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

Тогда, если у вас есть хранимые процедуры, некоторые из них не будут скомпилированы, если схема не на 100% правильна.Чистое начало процедур было бы еще одним шагом проверки для схемы.

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

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

IЯ большой сторонник написания модульных тестов для кода БД, но мне не нравится подход SQL Developers для этого.Сейчас я пишу тесты для приложения, но я пишу тесты на Ruby, и, похоже, это работает хорошо.Он также будет легко встроен в наш процесс сборки и автоматизированного тестирования.

Другой альтернативой является UT_PLSQL, который я использовал ранее, однако из-за природы PLSQL тесты становятся очень многословными, поэтому я решилиспользовать Ruby для моего текущего проекта.