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: Question about the Cactus architectur
Date Tue, 30 Apr 2002 20:08:24 GMT


> -----Original Message-----
> From: laurent.duperval@masq.ca [mailto:laurent.duperval@masq.ca]
> Sent: 30 April 2002 18:02
> To: cactus-user@jakarta.apache.org
> Subject: Re: Question about the Cactus architectur
> 
> On 30 Apr, Sheldon Wosnick wrote:
> > Laurent,
> >
> > Thank you and perhaps I was too verbose. I understand the structure
of
> the
> > runtime and the classpath. What I don't understand is why certain
test
> > classes (the code you write, not the runtime distribution from
Cactus)
> are
> > duplicated on the client and the server. I have read the classpath
setup
> at
> > http://jakarta.apache.org/cactus/howto_classpath.html but
> >
> > "What's missing" is what test case code goes on the client side and
what
> > test case code goes on the server-side -- not where to put it, not
what
> jars
> > and configuration files.
> >
> 
> All the tests cases go on both client and server. If I understand
> correclty,
> all beginXXXX() and endXXX() methods are executed on the client and
the
> testXXX() methods are executed on the server.
> 
> > Ok, here is what I mean. For a simple servlet redirector test case,
say
> > TestCase1, what would be the structure on the client and on the
server?
> >
> 
> Both.
> 
> > Am I missing something that this seems so obvious from a reading of
the
> > various literature in print on using Cactus, I am led to believe
that
> there
> > is an intentional duplication of some classes on both the client and
the
> > server and I am trying to understand that.
> >
> 
> It's necessary because you can't put the beginXXX() and endXXX()
methods
> in
> a separate calss.
> 

What you say is exact Laurent. When we designed Cactus, we had to make a
choice :

- for each test case that you have to write, force the user to write
methods in 2 classes

or

- write the methods in one class only but this class gets instanciated
twice (on the server side and one the client side - although each side
is not calling the same methods).

We chose solution 2 in order to diminish the overhead of creating a test
case (the compromise is a bit additional complexity to understand).

> > Is it simply says there that:
> >
> > Client-side Classpath:
> > ...
> > your test classes
> > ...
> >
> >
> > Server-side Classpath:
> > ...
> > WEB-INF/classes/<your test classes>
> > ...
> >
> >
> > I am trying to understand WHICH test classes go where. Not j2ee jar
or
> > runtime jar files, only Test case code.
> >
> 
> Anything that extends ServletTestCase or JspTestCase or FilterTestCase
> goes in
>  there. If you're only extending TestCase, you don't need to put the
> classes
>  in the web app (because most likely, you aren't testing any J2EE
stuff).
> 
> > I believe I read a chapter on Cactus on an XP, Open Source tools
book by
> > Wiley recently about certain test case classes being on both the
clieht
> and
> > server classpaths. In my environment that translates to separate
> projects so
> > that is why I ask.
> >
> 
> Oh.... Conceptually, your client makes an HTTP request to your server
and
> it
> executes that request. It just so happens that in this case, your
client
> and
> server are in the same test file instead of being a human and a
machine
> interacting.
> 
> Now if you say your client and your server are different, I don't
think
> Cactus
> is what you're after. I could be wrong, don't take my word for it. It
> really
> depends on what you're trying to test. If you're trying to test
methods
> from
> your J2EE objects, then Cactus is your friend. If you want to test
user
> experience (i.e. simulate a user accessing your servlet, clicking on a
> button
> and looking at the generated HTML), I think HttpUnit is more suited
> for that. But I'll let Vincent be the final authority.

That's right Laurent :-) (hey, you're a real expert now !). Cactus is
mostly a unit testing framework (white box testing of your server side
code).

> 
> L
> 
> --
> Laurent Duperval <mailto:laurent.duperval@masq.ca>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>



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