In response to Paul Taylor <paul_t100@fastmail.fm>:
> Guy Rouillier wrote:
> > Paul Taylor wrote:
> >> I am testing the code that extracts information from a read only
> >> database. These are UNIT tests so only interested in getting the
> >> right results given a particular set of data, anything else is a
> >> distraction.
> >
> > I don't understand your test environment. If all your code is doing
> > is extracting info from a database, why would you want to have
> > database management embedded in your test? Simply have a test
> > database already configured and running, then run your JUnit tests
> > against that existing database. That simple approach would obviously
> > work across all platforms.
> >
> > The only reason I can see for doing DDL in a unit test would be if the
> > end product will be doing such DDL.
> >
> Firstly the database side is quite straightforward, these issues with
> triggers and locking just don't apply for what I am doing. Secondly this
> is an opensource project and to enable others to contribute easily it is
> much easier if they can download the code and run mvn package to compile
> and test. Once you start introducing external database setups, and
> database configs things can easily start going wrong, and you can't
> share databases when doing automated testing
Gonna have to disagree yet again.
As an example, the Bacula project requires a database to run, and has a
full suite of testing stuff that multiple people run to help find bugs.
The thing that makes it doable is the fact that the setup process is
documented well enough that anyone who can follow instructions can set
up a testing system.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
