I will put these links and some additional guidelines in ruby-plsql-spec README as it seems it will be valuable for many PL/SQL developers who would like to try this out.

procedure process_customers_123 (bookkeeping_period in date)
is
begin
open cursor customers;
loop
fetch bulk collect into r_customers limit 1000;
exit when no_data_found;
forall i in 1..r_customers.count update customers set case when.., case when.., case when..;
forall i in 1..r_customers.count insert into other_table1 values …;
forall i in 1..r_customers.count update other_table2 set case when.., decode(), case when…;
– and so on
end loop;

end;

Good unit test should include both input data and results and should leave test database in the state as it was before test. Therefore it is better to keep test data generation inside unit test and not somewhere else – it helps both for readability for test (you see all inputs in test) as well as maintainability (if related things are stored in different places then it is harder to notice what else should be changed).

And I also recommend to separate unit tests (where you validate logic on specific small examples and test all different edge cases) from performance / integration tests where you test just some basic scenarios on large data volumes.

And last comment about “PL/SQL developer”. If the only tool you have is hammer then all problems seem to be nails :) Good software developer should have several tools and apply the right tool for the right problem. If PL/SQL is not a good language for testing (which could be seen from failure of utPLSQL project) then good developers should look for better tools for the job. And dynamic languages like Ruby or Python are better for such task. And you shouldn’t be an expert Ruby programmer to use this approach – the amount of learning of described framework probably is similar to learning GUI testing frameworks like Quest Code Tester or SQL Developer unit testing. And I am eager to help with advice and suggestions how to learn this approach faster :)

Maybe I’m not the target audience for this tool. I’m a PL/SQL developer, writing almost exclusively PL/SQL code. Introducing lots of Ruby code would be huge overhead all by itself. Your approach would probably be usefull to people that only occasionaly step out of Ruby to write a bit of PL/SQL and already have a working knowledge of unit testing for Ruby.

1) trivial code == trivial unit tests
2) non-trivial code == non-trivial unit tests

Because of this one has to take different approaches to readability for different scales of testing.
Want to test 3 line procedure that changes one field in a table with no triggers? Sure, you can easily generate tests using whatever methodology you like. But you shoud try to create tests that use data from some 20 different tables that totals to 400+ fields and 100+ total records that all can influence outcome and also include transaction management. Oh, and that outcome is not a single return value, but some possible inserts/updates in any number of other tables. That is actually too much data to *see together* for any test. So how should people manage it? Is it really that much better to store it in plaintext than it would be in database? Are CSV files better than INSERT INTO scripts? I think it is *data* that influences how things behave in *database*, so I say that it should reside in that same *database*. (You can store data generation scripts in version control, sure.) Anyway, does it really matter, how you generate your data on this scale? I’ve yet to see how can it not be ugly one way or another.

TL;DR version:
this does not address my problems with automated pl/sql testing, just ads another layer of abstraction. And we all know what Joel said about abstractions :(