----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol" <[EMAIL PROTECTED]>
Sent: Tuesday, July 24, 2001 3:53 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Vincent
>
> "With MO, the problem is for test writer to have to
> implement a mock container (or some parts of it)."
>
> I disagree with the assumption that test writers have to write a mock
> container to do MO. I think we can accomplish fully functional unit
testing
> with *patterns* rather than frameworks or mocked containers. To wit, I am
in
> the midst of writing an article on mock object testing with patterns that
> extends some ideas found here and at the mock objects project on SF with a
> new twist. I am attaching an early draft here with pseudo-code, if you
are
> interested. I am successfully using some of the patterns in a fairly
complex
> project currently. (Feedback is welcome and Alex, if you are reading this,
> could this help with your current EJB work?)
>
I think we are actually saying the same thing but using different words ...
:)
When I say "mock container (or some parts of it)", it can mean creating a
single mock implementation class (like MockHttpServletRequest) if that's the
only API you use from the Servlet spec. to mocking the full Servlet API if
you're using all of them.
Now, if you're saying that you actually don't need to write any mock
implementation at all and that it could be generated for you using a JDK 1.3
dynamic proxy then I only have 2 comments :
- it has to use JDK 1.3, which is a problem as JDK 1.3 is far from being
used everywhere (maybe in 2 years time)
- generating a mock implementation on the fly works for simple cases only
[BTW, have you looked at the EasyMock project ? You can find it on
http://tammofreese.de/easymock/index.html]. If you want to be convinced,
look at my previous post when I was giving the example on mocking
HttpURLConnection.
> The short of the matter is that I do not think we need to create a mock
> container to do unit testing with servlets. Now, integration testing is
> another matter, and that is where Cactus' in-container testing really
comes
> to the fore. Although it is my preference that unit testing be separate
from
> integration testing both in code and management, I think there are some
> solutions in your vote proposal that use method name space or external
> configuration to identify the methodology of different tests (mock versus
> in-container) that still allows the use of these patterns if it is
essential
> that Cactus manage everything to do with testing.
>
I think I am slowly understanding what you mean. You mean for example to be
able to count how many times a method of a mock implementatio has been
called ? How would Cactus cope with this ? Good question. I see 2 answers :
1- Cactus does not add this feature, either for MO or for IC.
2- Cactus adds this features for both MO and IC, which is easy to do as even
for IC there is a wrapper around the real Servlet objects
Now, regarding the verify() method, I am not sure. I understand it might be
nice if it is the mock object itself that implements the logic of
verification at it knows obviously about itself and what a correct state is.
Again here, we could either not add this feature or add it for both IC and
MO as I don't see it as exclusive to MO.
> "a good MO implementation would not return null or do
> nothing but rather would raise a runtime exception ... (like a
> NotImplementedException)."
>
> Very smart! I like it so much I added it to the draft patterns before
> attaching it here.
>
I'm glad you like it ! I have to say it is not my invention, I remember
discussing it at Xtc with the MockObjects project guys.
> "What you are saying in essence is "leave the choice open for the test
> writer
> instead of forcing him/her to use a given solution". This is fine but then
> what would happen when you run your test in IC mode. What would cactus do
> about the WebXmlQuery ? "
>
> Although this is probably moot at this point, WebXmlQuery or
> MockServletConfig would just serve as a utility to mock classes that need
to
> get some information from web.xml. Or, thinking of it another way, perhaps
> there is no place for web.xml when testing with mock objects since web.xml
> is fundamentally a container crutch?
>
My only concern is to try to have a test case that works both in MO and in
IC modes. Introducing WebXmlQuery will make thist more difficult.
I would be very happy to have your vote on the several polls I have sent.
> Tom
Thanks Tom for your participation.
-Vincent
