db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michel Beijlevelt" <...@lucka.nl>
Subject Re: unit testing code using torque
Date Mon, 18 Aug 2003 08:03:50 GMT
Hi all,

interesting discussion, as I'm pondering JUnit tests for my Torque based
project at this moment as well. I don't feel comfortable providing mock
objects in place because one might introduce errors that don't exist in
Torque, skip errors in Torque that are circumvented by the mock objects,
and it would be a lot of work too.

Currently we have some factories that create and maintain the Torque
database connection and we're working on some factories that create (and
destroy) test data through Torque which will be called from the setup and
teardown methods from the testsuites. Sure, this is slow but I'm very
willing to sacrifice this for better tests and ultimately better code.

We don't test the Torque functionality itself btw (apart from some Peer
extensions).

Hopefully this thread has a longlife, I'm very curious for soltions from
others.

BTW, does any one know if it's needed to save() all modifications that are
made to torque-based objects? As long as the objects aren't  destroyed,
the data should remain in cache, right?

gr. Michel



David Hainlin wrote:

> Hi Gary,
> I've done a fair amount of JUnit testing around Torque based projects.
Except in a few specialized classes, I've never found the need to
provide mock torque classes as most of the OM and business related code
really does depend on data Torque is fetching for me.  Most of my Torque
Peer extensions have been very straightforward. This type of approach
does require some careful DB planning, and a 'resettable' test database.
Most of my unit tests that work from different levels (say struts mock
objects) either back out any db changes or invoke a 'set up test db'
script.  This keeps everything repeatable.  On a larger project with
many developers, we had the good fortune to own all of the schema.  The
deployment was Oracle but I tested using mySQL with pretty good success.
On projects with less db control and with many developers running unit
tests, I've resorted to id ranging (David gets 1000 through 10000,
Ramesh gets 10000 through 20000, etc...).  If you plan ahead, you can
set your 'production' or 'integrated' torque id generation to start
above these levels.
>
> I'm curious about your thoughts on this I'd be interested in hearing
about your experiences.
>
> David




---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message