jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: SV: begin(...) and end(...) methods
Date Wed, 17 Sep 2003 18:20:50 GMT
Jason,

Ok, there's some mixup on terminology about client and server I think
:-)

There's no transmission of any database data between Cactus client side
and Cactus server side!

What you do is what I also do on my current project (and other projects
too). Let's imagine a typical project:

Myproject
  |_ conf
    |_ somedbdata.xml
  |_ src
    |_ java
      |_ [production source code]
    |_ test-cactus
      |_ [cactus test source code]

Let's imagine somedbdata.xml contains the database data to setup prior
to the test. Let's imagine it's also several megabytes! (as you'll see
we don’t care).

Here's my test case:

public MyTest extends ServletTestCase
{
    public void setUp()
    {
        // load the data to the database by loading the somedbdata.xml
file
        // Note: one advantage is that you can use the server's data
source 
        // to get a database connection if you wish (by doing a JNDI 
        // lookup).  You don't have too, though.
    }

[...]

    public void tearDown()
    {
        // Perform cleanup by loading whatever you want
    }
}

Although the setUp()/tearDown() are executed inside the container they
are still execute on your local machine which has access to the
filesystem and thus to the somedbdata.xml file.

Now, back to your points:

1/ Already answered
2/ Keys must be known before you run the test (in order to get
reproducible tests - very important). One solution for this is to clean
the database to a known state (much recommended).
3/ No data is sent by Cactus to the server side!
4/ yep, in tearDown()... ;-)

BTW, I'm still not convinced about the strategy to clean database data.
I still prefer to always setup the database in a known state (Sebastien
had the opposite view, so I guess your mileage may vary).

I have posted all the source code for my JUnit in Action book on
SourceForge. There is a full chapter on unit testing database
applications (with pure JUnit/Mock Objects and with Cactus). You can
check the source code for that chapter at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/junitbook/junitbook/datab
ase/

Hope it will help,
-Vincent

PS: BTW, I'm not opposed to special begin()/end() methods on the client
side but I have yet to find a convincing use case, apart from the
existing begin(WebRequest)/end(WebResponse) case.


> -----Original Message-----
> From: Jason Vinton [mailto:eccebonum@hotmail.com]
> Sent: 17 September 2003 09:06
> To: cactus-user@jakarta.apache.org
> Subject: RE: SV: begin(...) and end(...) methods
> 
> Vincent,
> 
> Concerning the use case, I hope I can provide you with something
> convincing.
>   The application that I'm dealing with is heavily dependent on the
db.
> On
> the client side, I'm adding data to the database that is guaranteed to
be
> unique to the individual test case run.  I send the webrequest to the
> server
> that will reference some of this unique data.  The knowledge of what
was
> added to the db for the test exists only the client side.  It's
> impractical
> to send it the server since it is MB's of data.  Regardless of whether
the
> test succeeds or fails, I need to clean all the data up to prevent
filling
> the database up with garbage.
> 
> Here are my major concerns as bullet points:
> 1.  A large amount of data is added to the database with unique
> keys/usersId/calulated values/etc. to ensure isolation from previous
> tests,
> concurrent users and concurrent tests.
> 2.  The some of the keys from part 1 must be known at the time the
> webrequest is formulated.  Therefore, the db set-up must be performed
on
> the
> client side.
> 3.  It is impractical/difficult to send all the required data for
clean-up
> to the server.  The webRequest already includes multipart/form-data.
> 4.  The clean-up must be preformed.
> 
> 
> 
> 
> Concerning end(), my apologies,  I was under the impression that the
> method
> signature was "end(void)" and not "end(WebResponse wr)"  I'm just now
> picking this up again after 2 months, and I was last working from a
June
> nightly build.
> 
> What I have is:
> 	public void endImport(WebResponse wr){
> 		logger.debug("endImport has been called");
> 		...
> 	}
> 	public void end(WebResponse wr){
> 		logger.debug("end has been called");
> 		...
> 	}
> 
> 	protected void tearDown() throws Exception {
> 		logger.debug("tearDown has been called");
> 		super.tearDown();
>     }
> 
> Based on your response, I fear that my understanding of tearDown() may
be
> incorrect.  The tearDown() above is called on the server side, but I
don't
> recall ever seeing any output from tearDown() on the client side.
> Unfortunately, I'm not in the position to quickly run a test at the
> moment.
> Either way, some form of client side, always-called, post-test
callback
> would help immensely.
> 
> Jason
> 
> 
> >From: "Vincent Massol" <vmassol@pivolis.com>
> >Reply-To: "Cactus Users List" <cactus-user@jakarta.apache.org>
> >To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
> >Subject: RE: SV: begin(...) and end(...) methods
> >Date: Wed, 17 Sep 2003 08:05:40 +0200
> >
> >
> >
> > > -----Original Message-----
> > > From: Jason Vinton [mailto:eccebonum@hotmail.com]
> > > Sent: 17 September 2003 08:03
> > > To: cactus-user@jakarta.apache.org
> > > Subject: Re: SV: begin(...) and end(...) methods
> > >
> > > Just to be clear on this point.  I would agree with Vincent that
the
> > > endXXX(WebResponse) should not be called in the event of a
failure.
> > > However, the client side end() method, to me, is slightly
different.
> >This
> > > I
> > > feel should be called.  Also, the documentation states that is
> >equivalent
> > > to
> > > the teardown() method on the server side, and one of the defining
> > > characteristics of the teardown() method is that is _always_
called.
> >I'm
> > > happy to dig into the code and suggest changes in the coming
weeks,
> >but
> > > first I'd like to get a deeper understanding of the client side
end()
> > > method's intended use.
> >
> >The doc may not be up to date, but the exact signature is
> >end(WebResponse)... There is no end() method as this is already
provided
> >by tearDown().
> >
> > >
> > > Jason
> > >
> > > One other minor point.  I face the same difficulty as mentioned in
the
> > > thread below.  I do db set-up in the begin() method on the client
> >side,
> > > and
> > > I would hate to have to move this to the server side.
> >
> >I don't understand what's the difference on doing this on the server
> >side or on the client side. Could you give me some use case?
> >
> >Thanks
> >-Vincent
> >
> > >
> > >
> > >
> > >
> > > >From: "Magnus Mickelsson" <magnus.mickelsson@telia.com>
> > > >Reply-To: "Cactus Users List" <cactus-user@jakarta.apache.org>
> > > >To: "Cactus Users List" <cactus-user@jakarta.apache.org>
> > > >Subject: SV: begin(...) and end(...) methods
> > > >Date: Wed, 17 Sep 2003 07:34:14 +0200
> > > >
> > > >Hi Jason,
> > > >
> > > >We talked a bit about this earlier on this list.
> > > >Take a look in the archives here:
> > > >http://www.mail-archive.com/cactus-
> > > user%40jakarta.apache.org/msg03865.html
> > > >
> > > >I agree with you - it would be helpful to have a method for
cleaning
> >up
> > > on
> > > >the client.
> > > >
> > > >/MM
> > > >
> > > > > -----Ursprungligt meddelande-----
> > > > > Från: Jason Vinton [mailto:eccebonum@hotmail.com]
> > > > > Skickat: den 17 september 2003 02:17
> > > > > Till: cactus-user@jakarta.apache.org
> > > > > Ämne: begin(...) and end(...) methods
> > > > >
> > > > >
> > > > > In the "Writing Tests" section of the cactus site there is a
> >section
> > > >that
> > > > > reads:
> > > > >
> > > > >
> > > > > Step 5 (optional): begin() and end() methods
> > > > >
> > > > >     begin(...) and end(...) methods are the client side
equivalent
> >of
> > > >the
> > > > > setUp() and a tearDown() methods (see previous step). They are
> > > > > called on the
> > > > > client side, before and after every test.
> > > > >
> > > > >     The begin() and end() methods are optional.
> > > > >
> > > > >
> > > > > I've observed that when the test fails, the end() method is
not
> > > called.
> > > > > It's unclear to me if this is a bug or by design.  I'm not
sure
> > > > > if this is a
> > > > > shared opinion, but I believe that it would be very helpful to
> > > > > have a method
> > > > > on the client side that is always called to do clean-up.
> > > > >
> > > > > Jason Vinton
> > > > > Moody's
> > > > >
> > > > >
_________________________________________________________________
> > > > > Fast, faster, fastest: Upgrade to Cable or DSL today!
> > > > > https://broadband.msn.com
> > > > >
> > > > >
> > > > >
> >---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
cactus-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> >cactus-user-help@jakarta.apache.org
> > > > >
> > > > > ---
> > > > > Incoming mail is certified Virus Free.
> > > > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > > > Version: 6.0.515 / Virus Database: 313 - Release Date:
2003-09-01
> > > > >
> > > >---
> > > >Outgoing mail is certified Virus Free.
> > > >Checked by AVG anti-virus system (http://www.grisoft.com).
> > > >Version: 6.0.515 / Virus Database: 313 - Release Date: 2003-09-01
> > > >
> > > >
> > >
>---------------------------------------------------------------------
> > > >To unsubscribe, e-mail:
cactus-user-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail:
cactus-user-help@jakarta.apache.org
> > > >
> > >
> > > _________________________________________________________________
> > > Get a FREE computer virus scan online from McAfee.
> > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> 
> _________________________________________________________________
> Try MSN Messenger 6.0 with integrated webcam functionality!
> http://www.msnmessenger-download.com/tracking/reach_webcam
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org



Mime
View raw message