same as #535 . i am working on a solution but i dont know if/when it'll be finished

@nrkmca , @Shoelace
I have a strong doubt about value of populating test results int database tables.
What is it that you're trying to achieve by this?
Storing data in tables is not a solution by itself - it's a mean to provide some solution.

What is it the problem statement, that you want to solve with this?

My concerns are:

• storing results in table makes test results bound to single database. You can't easily gather results from 2,10,100 databases.
• storing results bring maintenance burden as the results tables need to be purged/maintained somehow
• tables would need to become Public API as we do not want engineers to get tightly coupled with utPLSQL internals.
• once tables are part of public API, it will be hard to change them as the framework changes
• data in tables provides no value by itself, you need some reporting, analysis on top of it. Those are already provided by CI/CD servers like Jenkins as well as Sonar.

Let me join @jgebal on that. We discussed this topic multiple times and we came to exactly this conclusion. The database is the wrong place to store the history of test execution, it means the database becomes Stateful and it has different state on each run. Also you need to associate additional info with the run which is not available at the DB level, Git SHA-1 for example.
But the more important is that you need a separate additional tool to consume the results, to track it. For years the whole development community uses CI/CD tools for such things, delegating storing all the context and results of build and tracking history of changes.

yes i know and i agree.. i remember the discussions..
it does not belong as part of the main utplsql framework, however in my particular case at least it is going to be used as an interim step in replacing an existing custombuilt unit test framework.

so for me the problem statement is:
how do i seamlessly integrate utplsql into an existing larger custombuilt ecosystem? (that relies on results stored in a table)

Ideally all of the surrounding guff will be replaced also. but as with a lot of businesses it requires taking baby-steps.

Hi @jgebal, @Shoelace, @Pazus,
We are using one database with utPLSQL framework.
My requirement is to store the test case information in the existing tables like PLSQL_PROFILER_DATA/PLSQL_PROFILER_RUNs. Actually, I created 2 reusable quires one for actual result and other one for expected result. I will change the queries based on my test scenarios and capture output data in to 2 cursors. I need unique RUN_ID, USER_ID, Test Results (PASS/FAIL), TEST date and TIME will be populated in the tables. later, I will take this info for further steps. This will be useful for us to automate the process. Please check and help on this.

@nrkmca - are you working for the same company as I am?

@nrkmca PLSQL_PROFILER_DATA was never populated by utPLSQL v2 so it's hard to say it's an existing table from utPLSQL point of view - PLSQL_PROFILER_DATA is part of Oracle's DBMS_PROFILER.

Did you look into utPLSQL v3 code coverage? If you read the doc , you'll find how to make use of utPLSQL v3 code coverage. v3 uses DBMS_PROFILER as wee and PLSQL_PROFILER_DATA gets populated when you run utPLSQL with coverage.

Thank you Jgebal. I ran utPLSQL with coverage and able to populate the test case related information in the tables. I need little bit more information like unique run_id and test result in PLSQL_PROFILER_DATA/PLSQL_PROFILER_RUNs. but, You are saying which is not possible :-).

utPLSQL v2 didn't have code coverage built into it. You must be using custom solution.
V3 gives coverage in many formats

Possible with custom reporter
Closed via #589