turbine-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey D. Brekke" <jbre...@wi.rr.com>
Subject Re: turbine 2.3.1 and Unit Testing
Date Wed, 08 Nov 2006 18:45:19 GMT
These are difficult questions to answer in an email, but I'll share a 
little about what we do and maybe that will help out a bit.

Jeffery Painter wrote:
> I am trying to create unit tests for my application and trying to figure 
> out what is the current "best practice"... I have looked at EasyMock, 
> Cactus and Mockobjects... some of these seem old and others more 
> complicated to get setup.

We use all these options, each have trade offs.

The best thing for us has been to write our tests/classes so they don't 
depend on turbine proper.  This separation is very important, but not 
always easy.  Lately we've used CRC sessions to ensure the UI doesn't 
leak into our application.  Then we can have turbine dependent tests in 
one area, and keep the rest of our code POJO's.  This also makes 
dependencies easier to manage.

Mocks ( usually coupled with starting Turbine standalone ) are quick, 
but difficult to setup.  EasyMock is simpler than pure mock objects ( 
you can even mock classes now not just interfaces ) but not so easy to 
share setups among tests.

Our latest projects use cactus, jetty, and maven 2.  Cactus provides 
jetty test setup classes.  We just create a suite using these setups, it 
starts our turbine application running inside a standalone jetty, and 
then run all our in-container tests.  This lets us test rundata, 
context, actions, you name it.  Maven and cactus do most the heavy 
lifting.  The cactus plugin for maven 2 seems to be stalled so this is 
the best alternative at the moment.

> There also seems to be some lacking help in the area of setting up your 
> build environment with the proper testing jar's in order to get Eclipse 
> to run the unit tests properly..

We use maven/maven2 for this.  We also have spun our own custom ant 
build in the past.

> do you test against a database or do you just test functionality of 
> action and om classes?

Separation.  We test our actions using the above strategies ( 
mocks/cactus ).  We use generated Torque OM classes and generally accept 
that Torque is generating correctly.  When we do test changes we make to 
the generated classes or a tracer-bullet test, we try to use an 
in-memory db for tests ( like hsqldb ) for speed.  If we can't we do 
write a few the shoot all the way through to the db, just to be sure we 
have it wired up correctly.

> If you have a good working test case for an action class (and can tell 
> me how you setup your Eclipse environment build path) this would be of 
> great help.

Maven really helps here.  The eclipse plugin for maven sets up your 
classpath ( albeit based on turbine's published deps ) and away you go.

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                     ekkerbj@yahoo.com
http://www.bloglines.com/blog/jbrekke               ekkerbj@gmail.com


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


Mime
View raw message