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