Vincent et al
I attempted to post this earlier, but it apparently did not make the list.
At this stage in the game, with work on V2 starting, feel free to
respond, "Sorry, too late."
--
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?"
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?
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?
Tom
