Well, I've wanted to write these tests for a while. What finally drove me to it was the recent change in postgresql/mysql to save dates using DATE fields rather than as strings (sqlite still uses strings since it doesn't have date fields). However, a DATE field has a specific format for a valid entry which does not exist for a string, and the whole reason for 2.3.5 to be released so soon was that the date fields weren't valid. Unfortunately, what I really want with these tests is to have the real database validate the SQL to store and load the gnucash objects. No problem with sqlite. Big problem with mysql/postgresql. Now, embedded mysql might work... Hmmm......
Phil ________________________________ From: John Ralls <[email protected]> To: Gnucash Devel <[email protected]> Sent: Monday, August 31, 2009 10:58:13 PM Subject: Re: DBI backend tests 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
