—%test
—%parametrized(select name, birthdate from test_clients)
procedure tst_client_proc(a_name varchar2, a_birthdate date);

We can call it providing parameter values by iterating over sql statement using dbms_sql

We can also accept a function which returns a cursor.

Parameters should be mapped by name if the column aliases in the query correspond equally or by position if not.

Does this need to support query input? The model I have in mind is;

• a data setup step
• parameterised annotation passing list of items set up in data (without SQL)

With this you have the same capability, just without exposing SQL to the annotation.

My concern is opening up avenue of issues where users want to persist test / results data to drive tests rather that keep tests isolated and UtPLSQL clean from data storage.

I agree with @mathewbutler. I guess the better option is to preset all test data (like test_clients) and then iterate over it in a single test and check the results. Given that we have:

• Knowing that ut.expect doesn't stop execution after the first fail we will iterate through all given data;
• We don't have tons of test executions in reports about every single launch of iterated test but still keep data about all fails;
• I think that inventing a new annotation should provide some sort of a utility but we just take parametrizing (params, query or whatever) out of the test body and put it in a declaration part. Instead test-writer can do it by himself feeling free to write any kind of query and handle it in a way he wants it inside of the test body.

No offense, guys, just thoughts out of my head :)

We should look at something like this:
https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests

We should look at something like this:
https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests

I like the Functionality that the @MethodSource annotation in jUnit has. It provides a Stream of (multiple) parameters that are handed to the test executions. Like a rowtype in a way...