I would nominate either Axion or HSQL(Hypersonic). Hypersonic is used by Jetspeed, and is a good example to start from. It is much simpler to configure as it is all inmemory, and you can just edit the sql scripts to add data for your own tests. Then, in the future, if we used Torque to populate the database, then we could have multiple database "profiles" to test against.
I think for the more complex tests that are written using the Cactus framework, we need to provide all the services that typical Turbine apps require. I posted to the Turbine2 FAQ wiki page an example of testing Turbine actions from Cactus. I find that do in container testing is MUCH easier then working with a stack of Mock objects. I hope to dig into the port of cactus tests from /src/rttest to /src/test-cactus over the next couple days. Eric Pugh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 8:42 AM To: Turbine Developers List Subject: Re: Unit testing of security and scheduler service [EMAIL PROTECTED] (Jeffrey D. Brekke) writes: Sorry, there are *no* scheduler cactus tests, it was the cache service I was thinking of. > FWIW, there are cactus tests of the scheduler service donated when > some patches came from jetspeed and I think you could use cactus for > tests that will depend on external systems. That said, what are you > testing that needs the database? Aren't you just testing torque > then? Is there some way we can test the service logic without > requiring a database ( I'm not sure, just asking outloud )? > > "Quinton McCombs" <[EMAIL PROTECTED]> writes: > > > I am trying to write some tests for both of these services. The problem > > is that they require access to the database. > > > > I am going to be using mysql for the testing although any database will > > work. For now, I am going to add mysql to the dependency list (well, > > not now, but in a day or two when I am done). This is the only way that > > I know to get the jdbc driver into the classpath during the unit > > testing. Anyone else have a better idea on this? > > > > I also want to make sure that there are no objections to this idea... > > This will complicate the build process requiring a database to be setup > > first. > > -- > ===================================================================== > Jeffrey D. Brekke [EMAIL PROTECTED] > Wisconsin, USA [EMAIL PROTECTED] > [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- ===================================================================== Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
