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 [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.bloglines.com/blog/jbrekke [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
