Thanks Jeff, Right now, I think I'm going to try the in memory hypersonic database (http://hsqldb.sourceforge.net/) for testing. Seems very fast and so far it's working. I'll just use an ObjectMother to build up an empty database with test data for each test.
Rex -----Original Message----- From: Brekke, Jeff [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 8:14 AM To: 'Turbine Users List' Subject: RE: Torque, junit and unit testing > -----Original Message----- > From: Rex Madden [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 30, 2002 9:42 AM > To: 'Turbine Users List' > Subject: RE: Torque, junit and unit testing > > > Hi Jeff, > > I'm looking to test the code that uses the objects, as I think I can > assume that the generated objects work. > > It's funny that you mentioned the Object Mother pattern, > because I just > started using that as well. > > For the mocks, are you building another layer on top of the > objects, or > are you adding hooks straight into the Peers? I'm not sure if I can > conceptualize how you're doing that. I've doen it both ways. One way is to create objects that use the generated om objects. When I've done this I just create the interfaces so mocking is easier. Otherwise I just use the generated om classes, and stub out the save() method as I've shown below. > Either way, Torque doesn't seem well suited to automated > testing? Maybe > I'm better off with Cocoon or OJB? Not sure about either one. OJB is on my list of stuff to check out along with prevlayer. ================================================================= Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com > Thanks for the help, > Rex > > > > -----Original Message----- > From: Brekke, Jeff [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 26, 2002 10:00 PM > To: 'Turbine Users List' > Subject: RE: Torque, junit and unit testing > > Torque/Turbine do provide some obstacles to the test infected. In > situations where we don't want our tests to hit the db, we > just use the > generated om objects like they were pojo's and don't call methods that > hit > the db like save(). We've also used small mocks or shunts > via an inner > class which does nothing in the save(), something like: > > GeneratedOM om = new GeneratedOM > { > public void save() { } > }; > > This does get tricky setting up your model with populated objects. We > ended > up with large setUp() methods to init our test fixtures, sort > of driving > towards something like the ObjectMother pattern ( > http://www.xpuniverse.com/2001/pdfs/Testing03.pdf ) > > Are you wanting to test the generated objects or your code > that uses the > generated objects? > > ================================================================= > Jeffrey D. Brekke Quad/Graphics > [EMAIL PROTECTED] http://www.qg.com > > > > -----Original Message----- > > From: Rex Madden [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 26, 2002 6:22 PM > > To: [EMAIL PROTECTED] > > Subject: Torque, junit and unit testing > > > > > > Hi, > > > > I've been using Turbine without a database for a little > while and just > > started to take a look at torque for my persistence layer. > I do a lot > > of automated unit testing in my apps and was wondering how people > > approached testing on top of the peer objects. Usually, I > > try to write > > the bulk of my tests to not actually hit the database, > since opening a > > connection to the db slows things down. More often than > not, this is > > done with Mock Objects. However, looking at Torque, it seems > > that there > > aren't many interfaces to mock up. In addition, the generated peer > > classes all deal with the Torque singleton, which also poses some > > problems. > > > > So my questions: > > > > Is anyone doing XP type testing out there with Torque > WITHOUT hitting > > the database? > > If not, what kind of approaches have people been using for > db testing? > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
