At 9:36 AM +0100 7/15/01, Vincent Massol wrote:
>From: "Thomas Calivera" <[EMAIL PROTECTED]>
> > Although I am one of the original proponents of combining mock testing
>with
>> container testing, comments by Bob Davison and others are convincing wrt
>> keeping Cactus focused only on a specific type method of testing. I am
>> persuaded by the argument from engineering practices to keep the
>> responsibilities of a solution limited and specific. Cactus is already a
>> fairly complex framework and adding additional responsibilities will
>> complicate matters further. Does anyone disagree with the normative
>> statement of "simple, modular testing frameworks are better than
>integrated,
>> complex ones?"
>>
>
>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).
So if they are not the same kind of tests, what is the advantage of having the same
framework do them? Most of the suggestions I have seen assumed that it was valuable
and reasonable to switch back and forth between MO and IC testing by throwing a
switch. I think that you are correct that they are different, and therefore it is not
clear to me that configuration selection is meaningful. But if that is the case, how
does putting them in the same framework help?
>I have started the implementation of v2 this week end (rewriting from
>scratch) and I am 30% finished I would say (it's actually not that big). The
>main goal of v2 is to have a consistent way of writing test cases, be it for
>mock style, in-container style or functional style. The only complexity for
>the end-user will be to choose which TestCase class to use ... There will be
>several : ICWebTestCase, ICServletTestCase, ICJspTestCase for in-container
>and MOServletTestCase, MOJspTestCase to use mock implementations.
Could you explain a bit more about this "consistent way of writing tests"? You seem to
have something in mind, but I cannot tell what it is. And why do you feel a need to
have so many test case specializations. HttpUnit manages to provide support for both
functional and mock-object tests of servlets w/o specializing TestCase at all. Could
you explain your approach? The web page proposal contains virtually no technical
details.
>The complexity in Cactus v1 comes from the fact that the user need to
>understand that there are 2 parts for the tests : the client side and the
>server side. This complexity comes from in-container testing, not from
>Cactus. I think we need to rewrite (or rather reorder differently) the
>documentation on the web site so that it is easier to understand. What
>happens is that we have been adding documentation as time goes .... Now we
>should take the time to organize it into trails that will explain what to
>read and in what order ...
I definitely agree that documentation is key, and you have done a much better job of
it than I have :)
> > Another persuasive argument made by others is that the J2EE interfaces and
>> contracts of those interfaces are the central reference for both mock
>> objects and containers. In theory, containers run their *own* tests
>against
>> the specified contracts of the interfaces such that an application tested
>> against well-designed mock objects will work perfectly in a container so
>> tested. Otherwise, testing the containers' satisfaction of the interface
>> contracts through our applications is akin to making SQL calls from JSPs -
>> there is a fairly clear domain boundary violation. I partially understand
> > the practical reasons to test through our applications, but can anyone
>> resolve the
>> theoretical conundrum?
>>
>
>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.
Very true. And that does BTW lead me to wonder about the details of your current
in-container approach. Among the things that containers do specially is create their
implementations of HttpServletRequest, HttpServletResponse, ServletContext and so on.
But aren't you passing around Cactus implementations of these classes? Surely a true
in-container framework needs to somehow supply the container implementations of these
classes - and also initialize the servlets according to the directions in the web.xml
file as the servlet container does it. I am sure that I have missed something
(again), but if you are supplying your own implementations, aren't you hiding this
matter of proprietary implementations?
> > The current proposal is certainly workable and a fine job, but, given the
>> above, perhaps it is worth considering, before moving ahead too far, some
>> possible alternative proposals down the path of separating Cactus into two
>> projects, a Cactus-Container that runs tests *on a container itself* to
>> determine its satisfaction of the implied contracts and specifications and
>a
>> Cactus-Mock that is used by
>> application developers to test their servlets and JSPs?
>>
>
>Yes, I had thought about this. But it is a pain to maintain 2
>implementations in separate projects and again that was not the goal of
>Cactus (the ultimate goal of Cactus is to cover the full J2EE spectrum for
>unit testing, whatever the techniques used to do so .... and of course
>provided it remains usable and not too complex, which I believe we can
>achieve in v2).
Then it may be that you are focusing your efforts in the wrong place. You already have
a satisfactory in-container testing framework. HttpUnit can serve as a complementary
framework for mock object and functional tests. But what may be missing is a framework
for EJB testing. To be sure, you can do some functional tests of EJBs from an
application container, but I don't know of anything that allows testing of EJB
internals. Have you given any thought to that?
--
------------------------------------------------------------------------
Russell Gold | "... society is tradition and order
[EMAIL PROTECTED] | and reverence, not a series of cheap
| bargains between selfish interests."
http://www.httpunit.org | - Poul Anderson, "Iron"
