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
Gary Shea wrote:
I'm wondering what kind of solutions folks have come up with for unit testing code that uses Torque? I'm just starting to think about it and have some vague notion of subclassing Torque objects to prevent real db stuff from happening...
Gary
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
