Return-Path: Delivered-To: apmail-jakarta-cactus-user-archive@apache.org Received: (qmail 21758 invoked from network); 29 Apr 2002 07:29:03 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Apr 2002 07:29:03 -0000 Received: (qmail 19021 invoked by uid 97); 29 Apr 2002 07:29:13 -0000 Delivered-To: qmlist-jakarta-archive-cactus-user@jakarta.apache.org Received: (qmail 18955 invoked by uid 97); 29 Apr 2002 07:29:13 -0000 Mailing-List: contact cactus-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Cactus Users List" Reply-To: "Cactus Users List" Delivered-To: mailing list cactus-user@jakarta.apache.org Received: (qmail 18944 invoked from network); 29 Apr 2002 07:29:12 -0000 From: "Vincent Massol" To: "'Cactus Users List'" , Subject: RE: Concatenating two cactus tests? Date: Mon, 29 Apr 2002 08:23:46 +0100 Organization: OCTO Technology Message-ID: <003301c1ef4e$ceeed250$a5c8c8c8@octovma> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Gunnar, Why don't you store the object ids and sequence numbers in a static class variable of your ServletTestCase, on the cactus client side (if that's where you need them) ? You would also need to order the tests. The "correct" way I believe is to do the following : public void beginSecondTest(WebRequest) { // Call the server side to get the sequence number // using HttpURLConnection for example, // then use the returned values to set them up in // WebRequest } [...] In other words, get all the "environment" data needed for the second test before you execute it but without depending on any other test. Would that work for you ? (it is a bit of work, especially to parse the result). Maybe the use of a static variable is less elegant but is easier ... :-) We'll need to think if it is possible to Cactus to order tests on the client side and potentially offer a placeholder to store data that should be visible from one test to another. If you have any idea, feel free to propose them ! :-) Thanks -Vincent > -----Original Message----- > From: Gunnar Ole Skogen [mailto:Gunnar.Skogen@ergo.no] > Sent: 25 February 2002 08:51 > 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: > > > > For additional commands, e-mail: > > > > > > -- > > To unsubscribe, e-mail: > unsubscribe@jakarta.apache.org> > > For additional commands, e-mail: > help@jakarta.apache.org> > > > > > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > -- > To unsubscribe, e-mail: unsubscribe@jakarta.apache.org> > For additional commands, e-mail: help@jakarta.apache.org> > -- To unsubscribe, e-mail: For additional commands, e-mail: