I forgot one kind of test case class :
* WebTestCase for pure functional test case, i.e. testXXX() methods are not
called and there are no implicit objects.
Thanks
-Vincent
----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 5:31 PM
Subject: Re: [Cactus v2 - VOTE] Mechanisms for defining test types
> I have made an error in the description below. I have said that with
> solutions 2 and 3 there will only be a single ServerTestCase class ...
This
> is wrong of course ...
> There will be one test case class _per_ API type, meaning :
>
> * ServletTestCase for the servlet API, i.e. whenever we need to use the
> HttpServletRequest, HttpServletResponse and ServletConfig implicit objects
> * JspTestCase for the JSP API, i.e. whenever we need to use the
PageContext
> implicit object
> * TagTestCase for the JSP Taglib API, i.e. whenever we need to use the
> PageContext and BodyContent implicit objects (Note: maybe JspTestCase and
> TagTestCase will only be one class - we'll see)
> * FilterTestCase for the Servlet Filter API, i.e. whenever we need to use
> the ServletRequest, ServletResponse, FilterConfig and FilterChain implicit
> objects
> * EjbSessionTestCase for the EJB Session API, i.e. whenever we need to use
> the SessionContext implicit object
> * EjbEntityTestCase for the EJB entity API i.e. whenever we need to use
the
> EntityContext implicit object
>
> Thanks
> -Vincent
>
> ----- 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.
> >
> > ---
> >
> > Now, the only thing left is to define how Cactus will choose what kind
of
> > test to run in a given situation. See next mail for propositions on
this.
> >
> > Thanks
> > -Vincent
> >
> >
>
>
