----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 31, 2001 2:50 PM
Subject: Re: Test classification
> Vincent
>
> "The only remaining problem is : how to provide that ?...
>
> "Last remaining question : is it possible without incurring
> the cost of writing 2 test classes for each class to test ?"
>
> Following the emails between you and Alex, I think Alex's factory pattern
> for mock objects is a good start. However, I think your concern of
changing
> the in-container testing model is a valid one, especially since the test
> class code does change dramatically between the in-container testing
> offered by Cactus and the creation and population of mock objects
directly.
>
> Since Tomcat is the reference implementation for certain parts of the J2EE
> architecture, are we saying, by claiming a need for mock objects, that
there
> is a reference at the *interface* level that is "purer" than the
*reference
> implementation*? Is this valid?
>
> Is it possible to treat the collection of mock objects as just another
> container? If so, are we falling into the trap of effectively writing a
new
> container, which is a primary reason for Cactus' in-container testing
> approach?
>
Yes and no. The mock object implementation can be viewed as implementation
of a new container *but*
- it is a very simple one. There is almost no logic whithin the code, only
return statements. It is almost an interface ...
- it is implemented so that it is highly customizable,i.e. it is possible to
set any part of the environment
- it executes at light speed (almost) thus making it ideal for running tests
continuously, which is not the case with Cactus. I'd say we could imagine
the test process as follows :
- run mock test whenever the code changes (this is done from within your
IDE),
- every few hours, run the cactus tests to ensure the code works in the
container
> Tom
> http://calivera.manilasites.com
Vincent.
