jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robertson, Jason" <Jason.Robert...@acs-inc.com>
Subject RE: Concatenating two cactus tests?
Date Mon, 25 Feb 2002 19:10:52 GMT
Vincent, 

This is similar to the problems I had implementing the form login stuff.
While I understand the merits of the 'test should not be ordered'
philosophy, I can also see how this is a difficult constraint to live with
in a web environment. The problem is that sometimes you CAN'T configure a
test case to run independently because some of the information you need to
populate it with is essentially random data - a session id for instance. 

With form authentication, the way that I solved it could be considered the
concatenation of two cactus tests where the first test could be equated to
setting up the SERVER environment, i.e. not the METHOD environment, and the
second test could be the "real" test. And since the method is executing in
the context of the server, this server setup might be a necessity. In cases
where you rely on the app server to do things for you there is no way to
avoid going through the "proper channels" (i.e. no back door where you can
configure a DB or something to look like a user has logged in already).

So, should Cactus help with this scenario or should Cactus remain "pure" and
there be an extension of Cactus (or whatever) that helps to facilitate a
multi-trip setup capability. This will come up again as integrating form
authentication starts to happen, and while we could say it's OK to "cheat"
for this feature because it's part of a spec, having an architecture to
support this generically might be a better solution.

Admittedly, I having trouble thinking of any examples outside of
authentication that fall into this category (even Marko's initial question
seemed authentication related), but I'd guess that there are some J2EE
scenarios where multi-trip tests might be necessary since the app server is
doing more and more on your behalf. 

Jason

p.s. Should we move this thread to the developer's list? I'll let you do it
if you think so.

-----Original Message-----
From: Gunnar Ole Skogen [mailto:Gunnar.Skogen@ergo.no]
Sent: Monday, February 25, 2002 3:51 AM
To: Cactus Users List
Subject: RE: Concatenating two cactus tests?


Hi,
I know (and knew), but in my case the first test produces one or several
object ids and sequence numbers in the database which are returned by the
response and in turn are needed in subsequent test and this goes on down the
line - some test are dependent,  others not.
A clean unit-testing-way here would be to have the test data in the db ready
for each test... in my case that would mean more work - time I have not had
(yet). 
So what I have is not really unit tests, more like functional or
intergration testing, however, they serve their purpose and the
dependency/ordering is kept to a minimum.

Thanks for the reminder. 

/Gunnar 

-----Original Message-----
From: Vincent Massol [mailto:vmassol@octo.com]
Sent: 25. februar 2002 08:42
To: 'Cactus Users List'
Subject: RE: Concatenating two cactus tests?


Gunnar,

Just a note to tell you that, although you are, of course, free to write
it the way you want, this is _not_ how Cactus is intended to be used ...
;-)

The same best practices that apply to JUnit also apply to Cactus and one
of them is : each test case must be independent of others or if you
prefer to say another way : tests should not be ordered.

See http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html for
example.

Thanks for participating !

-Vincent

> -----Original Message-----
> From: Gunnar Ole Skogen [mailto:Gunnar.Skogen@ergo.no]
> Sent: 25 February 2002 06:41
> To: Cactus Users List
> Subject: RE: Concatenating two cactus tests?
> 
> Hi,
> 
> If B is dependent on results of A etc. I solved this by keeping the
> response
> from A in a static and using it to generate the B request. You have to
> administer the dependency logic yourself ( say A-response is needed in
D
> test also but the B-response is needed for the C-test etc.)
> 
> Gunnar Skogen
> 
> 
> -----Original Message-----
> From: Marko Balabanovic [mailto:marko@cellectivity.com]
> Sent: 22. februar 2002 15:33
> To: cactus-user@jakarta.apache.org
> Subject: Concatenating two cactus tests?
> 
> 
> I'm trying to construct a Cactus test that involves stringing together
> several HTTP requests.  Something like:
> 
> 1. Make request A (call method on servlet A)
> 2. Output is a list of items (don't know ahead of time how many will
be
> returned)
> 3. Make request B for each item on the list (call method on servlet B,
> passing a parameter from the output of the servlet A method, n times)
> 
> Does anyone have any advice on doing something like this?
> 
> The problems are that:
> - I can't really make both requests A and B inside one test method,
> since inside there I cannot change any request parameters (I only have
a
> handle on HttpServletRequestWrapper, rather that WebRequest)
> - Ideally I could dynamically create a test suite that includes one
test
> that checks request A and then n tests to check request B.  But to do
> this I need to see the output of request A inside my static suite()
> method.  This seems to be hard as I have no access to any
> request/response objects.
> - If I call another test case or suite from within my suite() method,
> all I get back is a TestResult object, whereas I really need some
custom
> output.  I can't even examine the state of the test case object, since
> the suite() method is executed in the client-side instance whereas the
> test itself happens in the server-side instance.
> 
> Should I be using some tool other that Cactus for this kind of
testing?
> 
> Thanks,
> 
> Marko Balabanovic
> 
> 
> 
> --
> 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>
> 




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


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