DBI backend tests
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/X). 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=..."? Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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/X). 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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DBI backend tests
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 To: Gnucash Devel 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/X). 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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DBI backend tests
John Ralls writes:
> 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.
I would only recommend this if you find that using (one of the) real DB
backends (sqlite, and against a /dev/shm-based db in particular) for
day-to-day testing is not fast enough. Maintaining an ad-hoc
persistence backend is a huge PITA … in many systems, though, it's less
of a PITA than a disruptively-long-running testsuite.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgp7uK1PrQoeg.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DBI backend tests
Phil Longstaff writes:
> There's no problem doing this for sqlite3 (just use /tmp/X). 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=..."?
./configure --test-mysql-url=… --test-pg-url=… ?
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DBI backend tests
Hmmm. I like it. I think it might work.
From: Josh Sled
To: Phil Longstaff
Cc: Gnucash Devel
Sent: Tuesday, September 1, 2009 9:26:54 AM
Subject: Re: DBI backend tests
Phil Longstaff writes:
> There's no problem doing this for sqlite3 (just use /tmp/X). 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=..."?
./configure --test-mysql-url=… --test-pg-url=… ?
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DBI backend tests
John Ralls writes: > 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/X). >> 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...) I suspect that writing a SQL parser that matched the MySQL and PG SQL parsers would be much more work than just calling out to the databases directly. We write out to test data files; I don't see why we can't write out to a test database too. Josh's suggestion of a configure switch is great, and it's something you can do while developing the code but means that 'distcheck' wont grab it (which is probably okay). > Regards, > John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
