Mailing-List: contact cactus-user-help@jakarta.apache.org; run by ezmlm
From: "Magnus Mickelsson" <magnus.mickelsson@telia.com>
To: "Cactus Users List" <cactus-user@jakarta.apache.org>
Subject: SV: Always execute a end method on the client-side?
Date: Wed, 3 Sep 2003 11:10:22 +0200
Message-ID: <HMEIJNMIMJPMHBHCGBPCAENHCAAA.magnus.mickelsson@telia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <05ea01c371e0$ddf80da0$2502a8c0@vma>

Hi Vincent,
thanks a lot for the clarifications. And thanks for the effort, you're doing
a great job - I'm sorry I burdened you with my rookieness ;-)

> Not in the current sources. I don't think it would be a good idea. The
> reason is that endXXX is used to assert the HTTP response and there
> won't be any if the test has failed on the server side and thus for sure
> the assert will fail, and it will mask the original error....

Ok, then I understand the flow a bit better...

> On that point, my belief is that database cleaning should not be done as
> it is a waste of time. Why not better set up the database in the correct
> state *before* each test? This prevents side effects and is inline with
> the unit testing methodology which says that all tests are independent.
> It's also clearer for a reader as he will know what data needs to be set
> before the test.

I agree, the problem is just that we have a pretty complex data model with
lots and lots of constraints. If one test sets up some data, adds some data
that relies on constraints and then fails (not cleaning the inserted data
up), the following tests working against the same tables of test data might
fail because we can't cleanly insert or update our setup. (And it's not
pretty to let the tests depend on each other when cleaning up)

Furthermore, we can't always just change PK/FK's to make it work, as some
columns have "unique" constraints in them, and other data rules.

So, we could:

* Workaround this by changing our test data (so that no test has even
similar data, and that it is unique in some columns, and valid according to
rules - some data has pretty strict rules associated to it). Anyone know of
a really intelligent test-data producing tool, or should I write one myself?
;-)

* Clean it all away using a custom stored procedure for quick flushing of a
set of tables, disabling constraints. The test database should not be very
big data-wise anyway, so the operation should not take too much time...

* Do something else.

> Anyway, that wasn't your question... ;-)
>
> Back to your problem. If you still want to do cleanup, you should do
> that in a tearDown() method, which is the recommended place (one
> advantage is that you can benefit from the container's connection pool).

Yup, that is the alternative to the scenarios above. Even though I am not
too fond of the idea of DBUnit JARs and test-data on the server, I'll give
it a go.

Take care and thanks again for the input,
Magnus
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 2003-08-19