----- Original Message -----
From: "Jari Worsley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 6:08 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> 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?
>
yes, that was my idea ... however, I still agree that even if the tests
might not be the same, if it is possible it would be good to be able to
interchange them ... see my previous mail of today on the subject (in answer
to Alex).
> 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.
>
There might be lots of server but the J2EE spec is limited and this what I
would like to address ... However you are right regarding for example
Struts. The question is : should Cactus offer MO implementations of Struts
so that writers of struts Action classes can unit test them easily ? Or
should this be located within struts itself ? My opinion would be to include
these objects within Cactus (as a start point), but in an "extension" area
so make sure they are separate (they can even be delivered as separate jars,
which I think is needed. Later on, they could be given to the struts project
to host them ... or ....
> >
> > 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.)
>
exactly ! :-)
> >
> > 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
-Vincent
