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?
"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?
"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
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?
Tom
