Vincent Massol wrote:
> >
>
> Cactus was never meant to be an in-container unit testing framework. Since
> the beginning the emphasis is on server-side unit testing, whatever the
> implementation. It happens that the first implementation was in-container
> partly because of my lack of knowledge on mock objects. Now I think that
> having a second implementation that gives a consistent solution that brings
> the best to the end user is a good way to go. Mock objects tests and
> in-container tests are not the same kind of tests (mock is meant to test
> your logic whereas in-container is more focused on ensuring that the
> relationship with the container works as expected).
>
Is it the case that Mock Object testing is akin to what folks consider
"traditional" unit testing, i.e. very quick, minimum dependance on other
libraries/setup, and done by a sole developer while programming.
and that In container leans more towards both unit but also "functional"
or "integration" (i.e. when you finally get your code running in
container and then IC in a dev/ed or live environment) testing?
Is that why VM sees a distinction between the types of tests that you
might actually run doing MO or IC?
Is that a problem? should cactus be confined to MO and "unit" testing,
or is it better to try to do all types of server side testing?
I think there is a problem when we say "server side testing" - there are
a f�"$k load of servers out there, and at the moment cactus can only be
used to test servlet containers. Maybe we need to decide whether it is
important to get a "horizontal" spread and try to provide a test
framework that provides limited functionality over a range of containers
- e.g. by adding EJB support, or whether we should go for a "vertical"
approach where we concentrate on providing a testing framework to fully
test on a particular type of server (in this case servlet engines).
I think the latter is more useful.
>
> The focus will have to be on the Methodology Guides which will explain when
> to use MO and when to use IC during the development life cycle. Very
> roughly, MO during development within your IDE, then once every fews hours
> or once a day or rather whenever the continuous build runs, the IC tests
> will also be run (along with the functional tests).
=- again the methodology and documentation are key. Frommy experience
(of service shops rather than product), there is very little real unit
testing that goes on, because it has bad PR and is percieved as
difficult to do. Half the battle is showing people that it is easy to
do. This comes from good docs as well as a good API.
(sorry about the rant but I believe that the docs are just as important
as the code framework.)
>
> er ? I could give a lot of counter examples that shows that the container
> either does not behave exactly as mentionned in the spec. or rather that
> there was a lack of clear specification at some point in the spec so that
> the container chose a proprietary manner to implement it. Rather than giving
> you sample I'd suggest you have a look at the changelogs of servlet engines
> (or application servers in general) from version to version. You'll see all
> the corrections that are done to comply more to the spec and all the bugs
> fixed .... !
Indeed, Resin gives many releases, but there is always a massive change
log between each release! Container developers are just as fallible as
us application developers :) being able to test against both IC and MO
can reveal where problems are hopefully quicker than the "developer
sitting down at machine with only MO tests scratching their head in
wonder that nothing works" style of problem solving.
Jari
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
