Комментарии 6
Так я и не осилил dbms_parallel_execute, кажется легче просто делать пачку джобов
BEGIN
FOR i IN 0 .. 9
LOOP
DBMS_SCHEDULER.create_job (job_name => 'j_jobname_' || i...Но если понадобится ожидать завершения всех и правда удобнее в таком варианте, спасибо за идею с connect by.
Так же смотрел в сторону dbms_parallel_execute и для сохранения логов подламывал пакеты UTP, но ваш способ dbms_output.get_lines элегантнее. Но в итоге не взлетело, остались на стеке Jenkins+Maven+Java+TestNG+Allure. Там и параллельность быстрее и результаты тестов нагляднее. Как вы обрабатываете результаты тестов?
Прошу прощения за длительное время ответа, немного увлёкся интересный работой).
Прогон тестов встроен в конвейер ci/cd (используем Bamboo+Jira), «планы» написаны на python (первые версии были на power shell). Все у нас построено на классовой модели (ООП), т.е. за юниттесты отвечает отдельный класс, который стартует тесты и парсит результаты выполнения. Если получаем зафейлиные тесты, задача возвращается на исходный статус с детальной ошибкой в комментариях с указанием, что и где сломали (в питончике парсится XML, через rest комментируется jira issue). Allure у нас благодаря JUnit парсеру обрабатывает UI тесты (запуск так же в конвейере) и рисует красивые картинки со статистикой выполнения плана бамбу. Юнит-тесты сервера, клиента и UI тесты прогоняются параллельно, независимо друг от друга.)))
Ну и тесты Oracle это про данные, как вы добиваетесь идемпотентности?
Если правильно понял вопрос - тесты генерируют эталонные данные, не везде пока, но мы работаем над этим. Естественно, зашиваться в тестах на определенные разрезы данных - не самое лучшее решение, т.к. данные - сущность непостоянная, поэтому от этого надо уходить. Тесты проверяют результат и время его достижения.
Параллельный запуск тестов utPLSQL (Oracle)