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