----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 26, 2001 8:07 PM
Subject: Re: [Cactus v2 - VOTE] *
> Vincent
>
> Please find my votes in one email to hopefully make collation easier for
> you. Although I am still not convinced of the need for Cactus to do both
IC
> *and* MO., I am going to vote for your solutions as you have presented
them
I'm calling Cactus v2 a proposition. It will not replace Cactus v1 for the
time being and will live somewhere separate in CVS (I'll send an email to
the list to explain what I have in mind in a short while). Consider it as an
experiment, as a test to see if it works !
> under the assumption that they are the only ones available. Also, I am not
a
> commiter, so I am not sure if I can technically vote, but here goes::
>
> Mechanisms for Defining
> +1: Solution 2 : Differenciation through testcase naming [class names mean
> no turning back, separate config file is a PITA, requires constant
> maintenance and synchronization of code base with config file]
>
> Choosing Classes To Run
> +1: Solution 1 : Through a java -D parameter [the other option entails
class
> names above]
>
> Making IC and MO Tests Work Together
> -1: Premise 1 : All HTTP parameter initialization in beginXXX() [I am
> generally against additional xxxXXX() methods)
however, we have no other choice (unless you have an idea) if we want to
have a common way of writing test cases for MO, IC and PF.
> +1 Premise 2 : We need an interface above the standard Servlet API. This
is
> because MO tests need new methods to initialize the state of the implicit
> objects. [Especially if includes verify()]
> ~0: Premise 3 : In order to be able to define different init values for
> different test cases, we need to expand the current Cactus web.xml mapping
> [need makes sense, web.xml is perhaps not the best place for it]
again, there is no other choice as web.xml is part of the Servlet spec and
init data _must_ be in there for real IC tests
> ~0 Premise 4, Solution 2b: [I think? I don't really understand the whole
> thought process here, but, in general, web.xml is a artifact of the
> container and mock objects can provide whatever they want for inits,
perhaps
> customizable through the calls to the expanded mock interface or separate
> mock config file]
I know MO can provide anything ! However, what I am looking for is a format
for writing test cases that is the _same_ for IC, MO and PF. If we can find
one then that would be great. It must not be a PITA for writing MO tests
though.
>
> Extensions to web.xml
> -1: [Web.xml should remain as simple as possible for production, so test
> info should go anywhere else, not sure about the ServletRedirector_XXX#
> thing, synchronization issues, etc. However, I have no other solution in
> mind, so perhaps scale my "vote" to ~0 for "that guy doesn't have a clue"
> :)]
see my comment above.
>
> Okay, I've voted. I'll return to my regularly scheduled arguing now :).
> Please feel free to respond to my other posts as convenient at a lower
> priority than support issues and pushing forward on v2. I'm happy with
> wherever you go with Cactus v2, but thinking through a lot of different
> issues and objections should make you feel more confident about your
> direction. Sort of like.... unit testing :).
>
again, thanks for your participation. Don't worry about the "I'm not
technically a committer" thing. I value your input as much as any other and
I'm looking forward to hear from anyone who wishes to participate !
> Tom
-Vincent
