Vincent Massol wrote:
>
> ----- Original Message -----
> From: "Jari Worsley" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, July 25, 2001 6:03 PM
> Subject: Re: [Cactus v2 - VOTE] Mechanisms for defining test types
>
> [snip]
> > > >
> > > > * Solution 3 : Externalize differenciation through configuration
> > > >
> >
> > > > We could modify the format of Cactus.properties to add for the
> following
> > > > configuration format :
> > > >
> > > > package1.package2.MyTestCase1.testXXX1 = MO
> > > > package1.package2.MyTestCase1.testXXX2 = MO, IC
> > > > package1.package2.MyTestCase1.testXXX3 = PF
> > > > ...
> > > > package1.package2.MyTestCase2.* = MO
> >
> > Or you could make it explicit in the code by adding something like a
> > "public abstract getAllowedTypes" method to ServletTestCase - then
> > implementors of a testcase have to express in code what "containers"
> > there tests can run in. You could do this in code on a method by method
> > basis if you wanted to, e.g. a code sample:
> >
> > public String[] getAllowedContainers()
> > {
> > return new String[] {"MC, "IC" };
> > }
>
> hey stop stop .... :-)
>
> All of this is very nice but there is a flaw (I think) ... You cannot define
> the behaviour of a test in the testXXX() method because this method is
> executed on the server side in the case of IC tests ...! (So you need to
> know beforehand if the test is MO or IC). You could put it in beginXXX() but
> then you need to make that method mandatory, which I don't like (and also it
> is not it's goal to define the type of the test!).
You could allow class level declaration of what containers you can run
in, but yes for individual testcase methods you would need to put code
in the beginXXX to ensure it is executed on the "client", and so the
test is either run or not.
Also, I am not saying that the TestCase class or method should be
"choosing" how it is being run, rather I ams saying it can express the
types of containers that it is expected to be run in. The leave the
actual configuration of what particular type of test you are running at
the time to a config file - so when running locally you may run the MO
tests, with your config file set to run only the MO implementation. Then
only TestCase classes marked as "safe" or "allowed" to run in MO would
run when you run your test suites. Then when you want to switch to IC
testing, change the config . Then testcases marked as safe for "IC"
would run - and if because you can allow multiple valid containers, then
some of the previous testcases marked as both MO, and as IC, would still
be run.
see?
it means that the person writing the code expresses what containers the
test is expected to be run in, and the person writing the config and
running the tests chooses what container "at that moment in time" is
actually run.
You could still allow people to limit in the beginXXX methods where the
test is run - and if they don't then default to MO as suggested. So what
I'm saying is an extension to your third suggestion.
Jari
>
> So what I am saying is that I don't see any way other than the 3 exposed in
> my initial email to specify the kind of a test ...
>
> -Vincent
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
