Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Статья уже 5 часов висит — и ни одного коммента. Все сидят ГМО обсуждают.
Автор — Спасибо за статью. И хоть с ораклом не работаю, но заставило задуматься над реализацией подобного на постгресе — на plv8 в принципе можно прикрутить движок тестирования и дергать его.
Минус данного подхода — зависимость от Oracle SQL Developer'а. Это означает, что запускать тесты в любимом многими ораклистами TOAD'е скорее всего не получится. Прикрутить тесты к автоматизированному билду на jenkins с запуском через sqlplus тоже не выйдет.
Мы используем самописный pl/sql фреймворк для запуска тестов в стиле junit'а, который активно использует savepoint'ы. Перед запуском теста фреймворк сохраняет состояние базы, выполняет тест, затем откатывает состояние базы до сейвпоинта. После этого сохраняет результаты теста. Есть нюанс с автономными транзакциями, но это мелочи.
https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/savepoint_statement.htm
В довесок имеем набор вспомогательных процедур для дампа таблиц и кверей, сравнения курсоров, итд. Дебажиться сплошное удовольствие. 700+ pl/sql интеграционных тестов. Полет нормальный.
Мы используем самописный pl/sql фреймворк для запуска тестов в стиле junit'а, который активно использует savepoint'ы. Перед запуском теста фреймворк сохраняет состояние базы, выполняет тест, затем откатывает состояние базы до сейвпоинта. После этого сохраняет результаты теста. Есть нюанс с автономными транзакциями, но это мелочи.
https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/savepoint_statement.htm
В довесок имеем набор вспомогательных процедур для дампа таблиц и кверей, сравнения курсоров, итд. Дебажиться сплошное удовольствие. 700+ pl/sql интеграционных тестов. Полет нормальный.
Полностью согласен на предмет привязанности к Oracle. Из того, что нам удалось найти во время работы над проектом, это был лучший вариант. Хотя, конечно, устанавливать все изменения приходится потом вручную.
Запустить SQL Developer на CI теоретически можно, так как у него есть режим CLI. Однако на практике требуется изрядная доля шаманства, ибо этот режим предполагает что SQL Developer установлен локально, и настроены нужные соединения с необходимой авторизацией.
Во время написания этой статьи, в нашем коллективе кристаллизовалась идея создать свой фреймворк для тестирования. Чтобы работал с большинством СУБД, и чтобы можно было его использовать как локально, для разработки, так и в рамках непрерывной интеграции, а ещё чтобы сами тесты можно было легко писать. Как только мы закончим базовый функционал, и выложим в открытый доступ, я обязательно отпишусь.
Запустить SQL Developer на CI теоретически можно, так как у него есть режим CLI. Однако на практике требуется изрядная доля шаманства, ибо этот режим предполагает что SQL Developer установлен локально, и настроены нужные соединения с необходимой авторизацией.
Во время написания этой статьи, в нашем коллективе кристаллизовалась идея создать свой фреймворк для тестирования. Чтобы работал с большинством СУБД, и чтобы можно было его использовать как локально, для разработки, так и в рамках непрерывной интеграции, а ещё чтобы сами тесты можно было легко писать. Как только мы закончим базовый функционал, и выложим в открытый доступ, я обязательно отпишусь.
Можно немножко информации — куда копать (кроме junit и oracle savepoint) дабы постичь подобие вашего фреймворка?
Фреймворк, над которым мы сейчас работаем представляет собой автономное консольное приложение, которое можно будет подключить к любой СУБД. При желании его впоследствии его можно будет обернуть в GUI.
От использования транзакций мы отказались в пользу воссоздания схемы с последующим риплеем скриптов с изменениями. Таким образом, тесты можно прогонять как на полностью чистой базе на CI, так и на девелоперской станции. Главное, чтобы критичных данных не было.
От использования транзакций мы отказались в пользу воссоздания схемы с последующим риплеем скриптов с изменениями. Таким образом, тесты можно прогонять как на полностью чистой базе на CI, так и на девелоперской станции. Главное, чтобы критичных данных не было.
utplsql
Мы также рассматривали данный вариант для тестирования процедур, но отказались по нескольким причинам:
1. SQL Dev отказывался работать с object types и/или nested tables
2. Невозможность запустить на Jenkins
Были найдены два решения и оба используются:
1. EclipseLink DBWS — утилита, которая создаёт обычное java web приложение(war) для запуска процедур, запросов, с помощью SOAP-WS.
У нас этот способ используется тестировщиками. Удобно, что можно тестировать процедуры, как веб сервисы с помощью SOAP-UI без написания pl/sql кода. Запустил утилиту, получил war, задеплоил (мы использовали glassfish), можешь тестировать. Если не меняется сигнатура процедуры, то не нужно перегенерировать war файл. Но мы наткнулись на несколько минусов:
2. Использование простого jdbc или враперов над ним для запуска процедур. Мы использовали инфраструктуру Spring для вызова процедур. Для этого пришлось написать по одному классу для каждой процедуры. В каждом классе объявляются входные и выходные параметры, а также row mapper. А дальше можно тестировать. Мы использовали связку Spring + DBUnit (Spring Test DBUnit). В результате был настроен Jenkins на прогон всех тестов. Единственный минус — это написания скучных row mappers.
1. SQL Dev отказывался работать с object types и/или nested tables
2. Невозможность запустить на Jenkins
Были найдены два решения и оба используются:
1. EclipseLink DBWS — утилита, которая создаёт обычное java web приложение(war) для запуска процедур, запросов, с помощью SOAP-WS.
У нас этот способ используется тестировщиками. Удобно, что можно тестировать процедуры, как веб сервисы с помощью SOAP-UI без написания pl/sql кода. Запустил утилиту, получил war, задеплоил (мы использовали glassfish), можешь тестировать. Если не меняется сигнатура процедуры, то не нужно перегенерировать war файл. Но мы наткнулись на несколько минусов:
- Была доступна только старая версия. Чтобы заработало на Oracle 12 пришлось самим собрать одну библиотеку с помощью maven.
- Не заработала процедура, входной параметр который был c типом CLOB. Для этого случая мы сделали обёртку для этой процедуры. Обёртка имел входной параметр VARCHAR2; преобразовывала его в CLOB и вызывала оригинальную процедуру.
2. Использование простого jdbc или враперов над ним для запуска процедур. Мы использовали инфраструктуру Spring для вызова процедур. Для этого пришлось написать по одному классу для каждой процедуры. В каждом классе объявляются входные и выходные параметры, а также row mapper. А дальше можно тестировать. Мы использовали связку Spring + DBUnit (Spring Test DBUnit). В результате был настроен Jenkins на прогон всех тестов. Единственный минус — это написания скучных row mappers.
Спасибо за статью.
Пару месяцев назад как раз выбирал XUnit для Oracle, инструмент из статьи отмёл, т.к. не использую Oracle SQL Developer.
Остановился на utPLSQL.
utplsql.github.io
(хм..., они пару недель назад на github переехали)
"+":
— всё можно хранить в базе и, следовательно, запускать все тесты скриптом из SQLPlus
— много разных assert'ов: запросы, коллекции, таблицы, курсоры
— возможность тестить не публичные функции/процедуры пакетов
Пару месяцев назад как раз выбирал XUnit для Oracle, инструмент из статьи отмёл, т.к. не использую Oracle SQL Developer.
Остановился на utPLSQL.
utplsql.github.io
(хм..., они пару недель назад на github переехали)
"+":
— всё можно хранить в базе и, следовательно, запускать все тесты скриптом из SQLPlus
— много разных assert'ов: запросы, коллекции, таблицы, курсоры
— возможность тестить не публичные функции/процедуры пакетов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TDD для хранимых процедур Oracle