----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 4:47 PM
Subject: [Cactus v2 - VOTE] Mechanisms for defining test types
> There are several possible mechanisms for choosing what strategy (MO -
Mock
> Objects, IC - In-Container or PF - Pure Functional) to use for a given
test
> case.
>
> * Solution 1 : Differenciation through different TestCase classes
>
> A test class containing test cases for MO style will extend MOTestCase,
one
> for IC will extend ICTestCase and one for PF will extend PFTestCase.
>
> The assumption here is that different strategies apply to different kind
of
> test cases. Tests using MO are using to test the code logic, whereas tests
> using IC are used to test container interactions and interactions between
> domain objects, whereas tests using PF are using to assert the returned
> results ...
>
> This mechanism is very simple. It has the drawback (is it a drawback ?) of
> preventing mixing the different kind of tests in a single test class file
> and it also means that an MO test will not be switched to an IC test
without
> modification.
>
> With this solution, the cactus.properties file will still contain the URLs
> for the Redirector proxies (for IC tests only).
>
> * 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
> case name need to start with the prefix "testMO" ("testIC" for IC and
> "testPF" for PF). For example : testMOGetInputStreamBadInputStream() ...
>
> The "advantage" (is it one ? Not sure but it brings flexibility for sure)
is
> that you can mix within a same test class different kind of tests (MO, IC,
> PF). It is also easy to implement tests that should run both in MO and IC.
> For example :
>
> public void testMOXXX()
> {
> // something
> }
>
> public void testICXXX()
> {
> testMOXXX();
> }
>
> The drawback is that the naming conventions are a bit harder on the user.
It
> is more intersting than solution 1 only if you think that it is a good
thing
> to be able to mix test case types.
>
> Note: Another solution in the same spirit would be to have an API like
> WebRequest.setTestType(WebRequest.TYPE_MO | WebRequest.TYPE_IC |
> WebRequest.TYPE_PF) but it would mean that the beginXXX() is now
compulsory,
> which would be a pain I think ...
>
> * Solution 3 : Externalize differenciation through configuration
>
> With this solution, there is a single cactus TestCase class (let's call it
> ServerTestCase) for all strategies (MO, IC or PF). It means that the
> different test case are undifferenciated in term of what strategy to use
to
> execute them. It could also means that we can write a test case for MO and
> then later execute it for IC without changing the test. I say "could"
> because I am still not 100% on how well this would work (see other
following
> email on the subject).
>
> 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
> ...
> 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.
>
> 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.
>
+1
-Vincent
