jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Newbie Cactus Questions
Date Wed, 25 Sep 2002 21:50:19 GMT
Hi Sean,

> -----Original Message-----
> From: Sean Schofield [mailto:sean.schofield@verizon.net]
> Sent: 24 September 2002 18:54
> To: cactus-user@jakarta.apache.org
> Subject: Newbie Cactus Questions
> 
> I'm new to Cactus and I have two basic questions?
> 
> 1)  Is it permissible/advisable to call another "helper" method from
your
> testXXX() method.  I know there is setUp() and begin() but this is
> basically a situation where I have 3 related testXXX() methods but I
need
> to set the request parameter differently depending on each of the
cases.

Yes, it is permissible to refactor your tests by writing helper methods.
Some would argue that you should build your TestCase around the fixture
and that you should have several TestCase classes for different
fixtures. However, this has nothing to do with Cactus and is more
related to JUnit best practices. If you search the junit mailing list
you'll find lots of answers to your question.

> 
> 2)  I'm not sure if this is appropriate but basically I have a series
of
> reports that my app generates and I'm trying to use cactus to generate
> each of them.  I could test the basic functionality of each step with
a
> single example but sometimes we run into problems where a specific
report
> is not available because the table in the DB was changed or a stored
> procedure was removed, etc.  Is it appropriate to use cactus for this
sort
> of thing?

Yes, it is! Cactus is about integration unit testing and what you
describe is exactly that! Actually, when I create Cactus tests, I very
often use the Mock Objects strategy (http://www.mockobjects.com) in my
Cactus tests. They are complementary. In your case, that would mean
writing mock classes, controlled by your test that generates the reports
you want.

Note: (slightly off-topic)

Another approach that I am currently looking at is combining AspectJ
with Cactus to be able to easily intercept calls and replace them with
mocks. But that practice will become really effective when AspectJ 1.1
is out (because currently aspectj only weaves aspects in source files
and not on bytecode - which version 1.1 will do). Thus, ATM, you need to
instrument your source code first, run the tests, then recompile again
but without aspects, etc.

Hope it helps,
-Vincent


--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>


Mime
View raw message