Paul Taylor wrote on 04.08.2009 17:04:
>> Well if you want to test the database, you will need a full database.
> It was a simple question, does Postgres have an embedded mode (which is
> still a full database) but unfortunately it does not.
I'm just trying to help get your test environment into proper shape. If you are not open for other
solutions, then ignore the rest of this email
> Yeah, but this is messy and low because you have to wait the database to
> be fully initilized before running the test.
Depends on what you mean with "initialize". You only need to run initdb once. After that you can
e.g. use DbUnit to populate the tables needed for testing.
If you do that, you can simply have an empty database cluster directory that you unzip before
running the tests suite.
> And for unit tests you
> should be start the database for each test, but wouldnt be possible with
> your method it would be to slow.
Well if you use something like DbUnit, you can simply leave the postmaster running and re-initialize
the tables for each test (something you would need to do with Derby as well).
> Furthermore this is a Windows only
> solution, there would be additional work to do to setup for Mac or Linux
No I don't think it's windows only. The batch file simply calls the already existings commandline
programs from the Postgres bin directory. They names are identical across all platforms. The only
thing would be the zipped database cluster as that is platform specific.
Btw: I find the H2 database a lot closer to Postgres than HSQLDB. The author is actively trying to
add compatibility levels for various DBMS. It might be worth looking into that as well.
But if you e.g. have triggers or stored procedures you'll have to use "the real thing".
We have e.g. unit test for one of our application that we ran on MySQL just for the fun of it, and
it failed miserable due to the different locking behaviour between Postgres and MySQL. I would
expect similar problems with heavy transactional tests with any embedded engine as well.
Thomas