Комментарии 14
Вполне оправданый отказ от тестирования через фронтенд. Так как вы через веб-API цепляетесь у вас максимально возможный охват слоев ( за исключением фронта). Конечно же бизнес процессы и целостность данных в таком приложени на первом месте. Но совсем про фронтенд забывать все-таки не стоит. А то придет беда, откуда не ждали :)
Сколько времени вам понадобилось, чтобы прийти к нынешнему решению?
Сколько времени вам понадобилось, чтобы прийти к нынешнему решению?
АБС ЦФТ-Банк — монстр, который должен умереть.
Для тестирования PL/SQL API могу ещё порекомендовать utPLSQL: есть компараторы коллекций, курсоров, объектов, иерархии тестов, автооткаты, оценка code coverage (через DBMS_PROFILER), умеет выдавать тестовые отчёты в формате JUnit/TeamCity. Для тестов с большими наборами данных покажет более высокую эффективность, так как данные не покинут пределы экземпляра Oracle.
Есть нюансы:
- тесты нужно писать на PL/SQL и деплоить на схему;
- движок построен на аннотациях, что может потребовать периодического сканирования спецификаций всех пакетов схемы, исключая системные пакеты — на схемах с большим количеством объектов будет тормозить на старте (обходится расширением списка исключений в ядре utPLSQL или использованием триггера для инкрементальных обновлений кэша аннотаций).
Мне известно 4 разных решения для тестирования от вендора. Вы имеете в виду машину тестирования? Можно подробнее чем не устроила? Тестирует тоже без «фронтенда».
Да, я про МТ. Очень сложная в изучении и сопровождении система. Для ее работы нужно минимум два стенда, на которые «нельзя дышать». Найти автоматизаторов на работу с ней на рынке — не реально. Ну и плюс это все в дистрибутиве, под лицензией — под себя не докрутить.
А про какие другие решения от вендора вы говорите? Вы именно про ЦФТ?
Названия пакетов с этими процедурами могут содержать id и отличаться на разных схемах. Как решен этот вопрос? Что будете делать после отказа от Oracle?
Id в имени процедуры появляется, если название исходной операции длинное. Эти Id (и следом названия пакетов) статичные, кроме расширений. Больше проблем доставляют id параметров на формах операций, которые могут меняться после пересоздания формы. Но, и то и то достается select'ом из таблиц methods, method_parameters…
Мы при формировании http-запроса динамически достаем требуемые id.
Не боитесь изменения API?
Опасаемся, да. Будем подстраиваться. Вряд ли тут будут единомоментные кардинальные изменения.
А как вы его выполняете если отправляете http запросы?
Наш фреймворк позволяет использовать и http-запросы, и выполнение select'ов в произвольном порядке. Commit там идет по большей части после OK в операциях. Затруднения может вызывать PLPCALL внутри операций — с ним надо индивидуально смотреть что происходит внутри конкретной операции.
Это как-то медленно, какая степень параллельности?
У вендора есть несколько решений для записи юнит-тестов на языке pl+, пробовали эти инструменты?
Это в один поток.
Есть ссылки на описания инструментов?
Да, я про МТ. Очень сложная в изучении и сопровождении система. Для ее работы нужно минимум два стенда, на которые «нельзя дышать».
Да, в этом проблема была. Но с появлением Oracle Multitenant, стало гораздо удобнее пользоваться МТ. Создал себе копию и ломаешь ее сколько угодно.
Хоть инструмент и массивный, но со своей функцией очень даже справляется. Если разработать набор правил по работе с МТ и придерживаться их, то она много раз спасет от багов в проде. Плюс, можно накрутить функционал «сверху», под себя.
У нас она встроена в CI. Перед установкой на бой каждое хранилище ставится на PDB МТ с прогоном всех тесты.
Что будете делать после отказа от Oracle?
Вот, тоже очень хочется узнать… Учитывая все эти события, санкции… Необходимость перехода на другую СУБД для банков.
Спасибо за статью! Очень интересно узнать, как другие банки решают те же проблемы.
И учитывая практически полное отсутствие информации по работе с ИБСО за рамками банка.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как (авто)тестировать Монстра