mp said:

>> One approach I've thought of doing is to write mock
>> versions of all the API libraries that provide some means
>> for controlling the return values and that don't do any
>> real database access. Then, the test code would 'use'
>> these rather than the real API modules, but this doesn't
>> really feel like the best approach because there are too
>> many unknowns at this point.

Actually, that's not all that bad an idea. Mocking up the entire API and play-testing it with the User community will help shake out the quirks early on. ("Ninety precent of the time we call api_open() followed by api_read_next(). Can we get things revamped so that the usual behavior of api_open() to return the first record, unless "no-read => '1' " is passed in the call?")

Developing a useful and friendly API is a real art. The earlier you can involve your User Community, the better your chances of ending up with somthing that they will use. Also, getting something out-there for then to play with begins setting up mind-share. Play-testing breeds a level of comfort -- "this is how it's going to work; it's not all there yet, but here is what I can expect to see when I do this call." And, Folks are much less prone to adding the tag "vapor-ware" to your work-in-progress if you really do have something out there for them to poke at.