DBI backend tests

[John Ralls]

On Aug 31, 2009, at 10:45 AM, Phil Longstaff wrote:

> I've started to write a DBI backend test.  Basically, it will create  
> a session with a set of data including (hopefully) all test cases.   
> It will then save that to a db, load it into another session, then  
> compare the data in the two sessions.
>
> There's no problem doing this for sqlite3 (just use /tmp/XXXXX).   
> However, since there are differences for mysql and pgsql, I'd like  
> to perform the test for all 3 databases.  Any ideas on how "make  
> check" could/should get urls for a mysql and pgsql database server  
> to use (or determine that there is no server available, so skip that  
> check)?  Argument to "make check" i.e. "make check -DMYSQL_URL=..."?

Yeah, don't. That is, don't actually talk to the real databases, just  
write a trivial pretend database (they're often called mocks) with the  
same function signatures and header names and so on so that you can  
build your test program with it instead of with pgsql or mysql.  
(Trivial so that the mock database doesn't need to be tested itself.)  
Ideally you should do the same for sqlite.

You can even provide accessors so that the test case can ask the mock  
database what it got, or preload it with data for the function being  
tested to retrieve.

You'll wind up with much better test cases. You will have to maintain  
the mock to keep it compliant with the database its pretending to be,  
but when it changes you'll wind up having to change the function  
you're testing anyway. This, by the way, is a really good reason *not*  
to use development builds of dependencies. (Not that I think you need  
one...)

Regards,
John Ralls