db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbre...@wi.rr.com (Jeffrey D. Brekke)
Subject Re: unit testing code using torque
Date Mon, 18 Aug 2003 13:14:54 GMT

Sounds like your testing factory should be in the torque project, testing itself.  

If you are comfortable that torque doesn't have any errors, then maybe
we wouldn't feel like we have to test access through torque to the db
in all our application tests.  Unless you are also really testing
things other than your code.

Michel Beijlevelt <mbe@lucka.nl> writes:

> 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?

Yes, this is how we do our programmer tests, skipping the save()
altogether.  I haven't used the caching though, the objects for sure
will continue to hold the data.  They're just pojo's at this point.


> 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

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com

---------------------------------------------------------------------
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