----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 4:30 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Vincent
>
> "The idea is to gather our efforts in a
> single place and make the resulting framework a defacto standard. For the
> moment, there is not a single mock object framework that I see as a
standard
> framework. "
>
> Do you really need a framework for mock object testing? I see a lot of
> attempts to take a set of interfaces, like the J2EE Servlet interfaces,
and
> then slowly stub them out in discrete mock implementing classes as needed
> until you end up with a MockSomeInterface class that provides some
> implementation for all methods of the mocked interface used by classes in
> your application, with all the other methods having no implementation or
> return nulls. I think you deserve the credit for pointing out that, by
doing
> this, you eventually end up rewriting a container, thus the impetus of
> Cactus' in-container testing. Do you still think this is true?
>
I think that it is important to lower the cost of writing unit tests
whatever the strategy. With MO, the problem is for test writer to have to
implement a mock container (or some parts of it). I think that a generic
mock implementation would help a lot and I don't see it as a major task (the
Servlet API being stable and finite and the mock implementation only
returning data set using setters, it is quite doable - even if to be 100%
correct, the implementation will need to be refined and corrected for some
time ... but the goal is not to be 100% sure your tests will run fine but
rather reach a 80-90% which is already fine and then use IC to refine it
further and breach into the 95-99% range _if_ needed).
Note: BTW, I think that a good MO implementation would not return null or do
nothing but rather would raise a runtime exception ... (like a
NotImplementedException).
> "How do you set up which URL to call ? PF need a real URL, IC need a
> servlet redirector URL with optionally a simulated URL (setURL() as in
> Cactus v1) and MO only need optionally a simulated URL."
>
> With MO, at least, all you really need to do is return the proper
attributes
> used by the test subject from the MockHttpServletRequest. Whether the
> container turns querystring variables into retrievable attributes through
> the HttpServletRequest implementing class is a fairly basic container
issue.
> Or are there other URL complexities here?
>
I don't understand your point. But the answer to the question is simple,
simply use the setURL() API whatever the strategy (IC, MO, PF). In IC, the
real URL to call will come from cactus.properties, in MO there is no URL and
for PF Cactus will the one sefined in setURL() (which becomes mandatory for
PF tests BTW).
> "These APIs are richer for MO as
> in IC lots of init data come from web.xml"
>
> IMO, code generation is the least desirable option as it introduces too
many
I completely agree, so we'll try to avoid this. This is what I have put in
the different proposition.
> variables. If the concern is getting information from web.xml, then
perhaps
> there is a place for an "assistant" class for MO's that let's you "query"
> information from web.xml. Thus, when you write the MO, you simple create
an
> object of WebXmlQuery, direct it to the appropriate web.xml file, and then
> use its methods to retrieve any contextual information you need. Perhaps
you
> can even wrap this over, under, or around ServletConfig. Does this
> make any sense?
>
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 ? ... What I am trying to do is having a way to write
tests that is similar in MO and in IC (as much as possible) so that running
a MO test in IC mode is transparent. All this with no overhead for test
writers as much as possible ...
I have actually asked this question in the vote mails.
> Tom
Thanks again.
-Vincent
