Mailing-List: contact cactus-user-help@jakarta.apache.org; run by ezmlm
From: "Vincent Massol" <vmassol@pivolis.com>
To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
Subject: Chaining of tests (was RE: beginXXX and endXXX jsp problems)
Date: Thu, 15 Apr 2004 11:24:35 +0200
Organization: Pivolis
Message-ID: <011c01c422cb$b20a6e30$2502a8c0@vma>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: 
 <3C939AFDC629BE45849CFC47D848614E425AAC@sf1-its-exc-002.exchange.kmv.com>
Importance: Normal


> -----Original Message-----
> From: Shvartsburd, Feliks [mailto:Feliks.Shvartsburd@MKMV.com]
> Sent: 14 April 2004 21:00
> To: Cactus Users List
> Subject: RE: beginXXX and endXXX jsp problems
> 
> Hi Vincent
> 
> I don't' know what's causing getText to return an empty string or
null. I
> looked at getText implementation and as far as remember it's just a
> wrapper to the code below. That's why in my email I said that it was
> weird. Unfortunately I don't know the problem if any exists? 

Ok. Then we'll consider there are no problems so far... ;-)

> I do have
> another question actually. It seems that either I'm doing something
wrong
> or cactus is not maintaining http session using cookies. Here's
scenario.
> I have several test cases. First one is just login into the system. At
the
> end of beginXXX I use the following:
> 
>  wr.setAutomaticSession(true);

Cactus is about performing unit tests. As such it is not a functional
testing tool such as HttpUnit, Canoo Webtest, etc. 

Cactus tries its best to *isolate* each test. For example, it ensures
that a new session is created for each test.

See also the Cactus FAQ for some more details on this.

> 
> 
> When I execute the next test case I assume that cactus maintains the
> session and I try to execute something on the server side inside of my
> testXXX method. I get an error from the server stating that my user is
not
> logged in. That led me to believe that cactus either didn't send the
> cookie along with my request or the cookie didn't match what was
expected
> by the server for the user what logged into the system in my first
test.
> So, what I did is this:
> 
> In my first test inside of my endXXX I do this:
> 
>  Cookie ws = response.getCookie(SessionConstants.WL_COOKIE);
>  Util.storeCookie(userName, ws.getValue());
> 
> 
> In all my consequent tests inside of beginXXX I do this:
> 
>  String cookie = Util.getCookie(userName);
>  if(cookie != null)
>     wr.addCookie(SessionConstants.WL_COOKIE, cookie);

There are 2 ways to implement this:

1/ By persisting the cookie (what you are doing) or saving it in a
static variable for example.

2/ By logging in the user in the setUp() method (which is executed on
the server side). Usually logging in the user is only a matter or either
calling a method or setting a variable in the HTTP Session.

I personally prefer option 2 as this step is part of the test fixture.
Remember that for unit tests, the test fixture is in charge of
configuring the environment in which the test executes.

> 
> Everything works just fine. It seems kind of weird that cactus doesn't
> have this feature built in (or like I said I'm really doing something
> wrong). If you can let me know what is it that I'm not doing right I'd
> appreciate it.
> 

Thanks
-Vincent


> Thanks
> 
> felix
> 
> 
> 
> 
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> Sent: Wednesday, April 14, 2004 11:39 AM
> To: 'Cactus Users List'
> Subject: RE: beginXXX and endXXX jsp problems
> 
> 
> Hi Feliks
> 
> I've never had any issue with getText() so far. Could you please
> elaborate so that we can fix the problem?
> 
> Thanks
> -Vincent
> 
> > -----Original Message-----
> > From: Shvartsburd, Feliks [mailto:Feliks.Shvartsburd@MKMV.com]
> > Sent: 14 April 2004 20:24
> > To: Cactus Users List
> > Subject: RE: beginXXX and endXXX jsp problems
> >
> > I have not had any luck using getText in the past (which is kind of
> > weird). Instead I use the following:
> >
> > public void endXXX(WebResponse response) {
> >     try {
> >      java.io.InputStream in = response.getInputStream();
> >      BufferedReader br = new BufferedReader(new
> InputStreamReader(in));
> >      String line = null;
> >        while ((line = br.readLine()) != null ){
> >          System.out.println(line);
> >         }
> >       }
> >       catch (Exception e){
> >         e.printStackTrace();
> >       }
> >     }
> >
> >
> >
> >
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@pivolis.com]
> > Sent: Wednesday, April 14, 2004 11:19 AM
> > To: 'Cactus Users List'
> > Subject: RE: beginXXX and endXXX jsp problems
> >
> >
> > Hi Conan,
> >
> > Maybe you can check the sample application that comes with the
Cactus
> > distribution. The servlet sample would be the best for you. It's
> located
> > in samples/servlet. Check out the Cactus tests, located in src/.
They
> > contain a full suite testing almost all aspects of Cactus. Do a
> > search/grep for getText() and you'll find the test.
> >
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Conan [mailto:woodsc@f00f.net]
> > > Sent: 14 April 2004 19:41
> > > To: Cactus Users List
> > > Subject: Re: beginXXX and endXXX jsp problems
> > >
> > > Thanks, I've read the document, so I'll rephrase my question.  Can
> > > someone show me how to use getText() to return something other
than
> an
> > > empty string?
> > >
> > > On Wed, Apr 14, 2004 at 09:56:43AM +0900, Kazuhito SUGURI wrote:
> > > > Hi,
> > > >
> > > > In article <20040413181607.GG4858@f00f.net>,
> > > > Tue, 13 Apr 2004 11:16:07 -0700,
> > > > woodsc@f00f.net (Conan) wrote:
> > > > woodsc> Hmm, I didn't realize I had to, as none of the examples
> > seemed
> > > to
> > > > woodsc> require it.(although I guess it makes sense :) )
> > Unfortunately,
> > > it
> > > > woodsc> doesn't seem to be helping.  I imagine I'm missing a
core
> > > concept here
> > > > woodsc> somewhere, so I'm going to outline what I think should
be
> > > happenning.
> > > >
> > > > A document at
> > > > 	http://jakarta.apache.org/cactus/how_it_works.html
> > > > might helps you.
> > > >
> > > > Regards,
> > > > ----
> > > > Kazuhito SUGURI
> > > > mailto:suguri.kazuhito@lab.ntt.co.jp
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
cactus-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> cactus-user-help@jakarta.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
cactus-user-help@jakarta.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> >
> >
> >
> > -----------
> > The information contained in this e-mail message, and any
attachment,
> is
> > confidential and for use solely by the intended recipient.  If you
> have
> > received this message in error, please delete this message
> immediately.
> > Although Moody's KMV makes every effort to protect its computing
> > environment from malicious code, Moody's KMV is not responsible for
> any
> > virus or other type of suspect code that may be transferred via this
> e-
> > mail message.
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> 
> 
> 
> -----------
> The information contained in this e-mail message, and any attachment,
is
> confidential and for use solely by the intended recipient.  If you
have
> received this message in error, please delete this message
immediately.
> Although Moody's KMV makes every effort to protect its computing
> environment from malicious code, Moody's KMV is not responsible for
any
> virus or other type of suspect code that may be transferred via this
e-
> mail message.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org