Back to the main topic. I don’t have unit tests, but I’ve started to keep a library of code examples, and some of those examples are queries that expose bad data.

utPLSQL is a great tool as far as I am concerned, but it was not good enough to convince DB developers to change the way they worked. I think that the problem is exactly in all the boilerplate code - to do these three simple assertions you would have to declare the package spec, package body, function etc… because concatenatetrings is a stored proc with output parameter, not a function, this adds three other boilerplate lines to call the proc separately from the assertion, and another line to declare the variable to store that output parameter. DbFit does all that boiledplate code automatically and allows DB developers to focus on assertions.

You say it would take 20 lines to check 3 concatenations work correctly. If I ignore the boilerplate code, in utPLSQL this looks like this, which is not a million miles from the equivalent in JUnit:

utAssert.eq(’Concatenation 1′, ConcatenateStrings(’Hello’, ‘World’), ‘Hello World’);
utAssert.eq(’Concatenation 2′, ConcatenateStrings(’Arthur’, ‘Dent’), ‘Arthur Dent’);
utAssert.eq(’Concatenation 3′, ConcatenateStrings(’Ford’, ‘Prefect’), ‘Ford Prefect’);

…and if you were doing more assertions, you’d extract that repeated line into a procedure.

I would generally advise against using meta-languages for this, especially internal meta-languages. It’s short-term gain, but long-term this kind of thing never worked for me. You need to train new people to use the meta-language, and the meta stuff is always incomplete. While there are good meta-languages and generators for database views and tables, when advanced features like queues, or even basic PL/SQL stored procs get into play, this meta-language stuff just falls apart.