Oracle groks SQL, dunnit? The trick is to write the queries you need for UnitTest''''''s, run them once in Oracle, save the results to files or global objects in your test OODB or wherever you like. Then the InMemoryImpostor just looks up the SQL in a dictionary and answers the query result.

Sure, it won't do everything ... but combined with a few tests to make sure the Oracle interface itself works, you can orthogonalize the RDB testing way down to a bunch of small tests giving fast and big results.

''Sure, recordsets can be written to files and brought back for testing purposes. A pass-through DAL could have a switch to flip on testing mode, in which case it would retrieve the appropriate recordset whenever the associated query was passed in. But this is select-only; if you're testing the ability to make a series of database changes in combination with the selects - typical RDB app behaviour - then I think the InMemoryImpostorForOracle is going to get heavy faster than the app I'm trying to test. Which takes me back to ExtremeProgrammingChallengeThirteenPointFive.''