If we have logic in a database (and we do)....

Automated/unit/integration testing...Need data setup & teardown.

Might be multiple tables with foreign key constraints. 

When we insert the data, we'll get new keys, so we need to remember the keys generated.

Teardown: might be "delete the data" or might be "just leave it for the next test" or might be "delete SOME of the data" (which might have been generated by the test and not part of the setup).

Setup note: if teardown isn't "delete the setup data", then the setup should be more like "find the data from the last test run or create it".

"Find the data from the last test run" would probably look like "find config data matching the following list of requirements" (followed by the requirements).Requirements might be: rows having a given set of column values (or ranges of values); related records (e.g., children or parents) have certain column values or cardinalities (no children, exactly one child,2+ kids, exactly n kids, etc.)

Setup might be specified as simple column values for rows, with children/related records having FK relationships.

OR... might be specified as sproc names with parameter values (e.g., config-writing sprocs). Those sprocs are not under test and are assumed to be working properly. (Although they could have their own associated tests.)

Finally, you might need to specify APIs to be called, along with parameter values. That's basically code to be run. For that, maybe we just specify a chunk of code to be compiled (C#? Java? Python? Javascript?) and a directory of dependencies (DLLs, jar files, etc.). Of course, at this point, why would we do this in a config file when we have an editor and compiler already at hand, since we're developers coding up automatic tests?

So, we might need to find some data and then code up some other related data (so, we'd need to use data item names or ids after lookup to create related data).

Could use regular expressions or LIKE expressions to find data.

Creating data for setup could also include a confirmation that the teardown will work properly. (Or do we need that?). Return number of objects (rows?) created, and in teardown, if we don't delete exactly what we created, log a loud warning.

I would specify all this in XML.