Vincent Massol wrote:
>
>
> > * Solution 1 : Differenciation through different TestCase classes
not sure I fully like this. I say why below.
> >
> > * Solution 2 : Differenciation through testcase naming
> >
> > With this solution, there is a single cactus TestCase class (let's call it
> > ServerTestCase) for all strategies (MO, IC or PF). However the
> > differenciation is done through test case naming. For example, each MO
> test
Better.
> >
> > * 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" };
}
or perhaps you could be more explicit/typesafe and have constants for
the allowed containers?
Or if we wanted to go a bit more "OO"... ;) How about having a simple
interface that describes a "Container", then have implementations for a
MO container, and for IC Containers - then a TestCase can express in
code exactly what containers it can sensibly be run in, and by returning
a Container object, you have an Object reference to "hang" lots of the
other details off - so when the Cactus code is getting an connection to
run the test, you would get it off the Container implementation
depending on how the external configuration is set up.
You could have method by method control over which tests to run in which
container by using some sort of assert before running the method - to
provide finer grained control if you need it. i.e. say you have a
testcase with 20 methods, and the testcase is itself declared to work
with MO and IC, if there were 5 methods that absolutely must have a
container to work, then in code you could do:
public void testDoSomeICTest()
{
checkContainer("IC");
// rest of test code.
}
Then as VM says below, use an external configuration file that defines
what container you are actually using when you run cactus tests.
Is this making any sense to anyone?
More sample code (in pseudo-ish code).
public interface Container
{
AbstractClient getClientHelper();
TestCaller getServerTestCaller();
// etc.
}
I have made up some interfaces here, an "AbstractClient" interface - to
return the client side implementation for the testcontainer, and
"TestCaller" - to return server side implementation. There currently is
no TestCaller interface. There is an AbstractHttpClient class, but with
a bit of work perhaps this can be renamed - at the moment it only has
one method of doTest, that returns an HttpURLConnection - I'm sure we
can refactor that dependency out :). The returned connection is only
used in the endXXX method AFAIK.
> > ...
> > package3.* = IC
> > ...
> >
> > This adds more work when defining a test case (except when using
> wildcards)
> > but brings the advantage of being able to specify that a test will work
> both
> > in MO and IC for example.
which I think is very important. - any test that I write for MO should
pass in a real container, so I would like to easily run all MO tests in
my container - can anyone think of a MO test that shouldn't pass IC? Or
have I completely misunderstood how the whole Mock Object thang works?
> >
> > We could have a default rule saying that when nothing is specified in
> > Cactus.properties for a given test case, it is by default a MO test case.
> >
>
yes - make the configuration as easy as possible please, because I'm
_really_ lazy ;)
> +1
>
> -Vincent
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
