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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > Sent: 22. februar 2002 15:33 > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:cactus-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-user- > [EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
