Vincent
Please find my votes in one email to hopefully make collation easier for
you. Although I am still not convinced of the need for Cactus to do both IC
*and* MO., I am going to vote for your solutions as you have presented them
under the assumption that they are the only ones available. Also, I am not a
commiter, so I am not sure if I can technically vote, but here goes::
Mechanisms for Defining
+1: Solution 2 : Differenciation through testcase naming [class names mean
no turning back, separate config file is a PITA, requires constant
maintenance and synchronization of code base with config file]
Choosing Classes To Run
+1: Solution 1 : Through a java -D parameter [the other option entails class
names above]
Making IC and MO Tests Work Together
-1: Premise 1 : All HTTP parameter initialization in beginXXX() [I am
generally against additional xxxXXX() methods)
+1 Premise 2 : We need an interface above the standard Servlet API. This is
because MO tests need new methods to initialize the state of the implicit
objects. [Especially if includes verify()]
~0: Premise 3 : In order to be able to define different init values for
different test cases, we need to expand the current Cactus web.xml mapping
[need makes sense, web.xml is perhaps not the best place for it]
~0 Premise 4, Solution 2b: [I think? I don't really understand the whole
thought process here, but, in general, web.xml is a artifact of the
container and mock objects can provide whatever they want for inits, perhaps
customizable through the calls to the expanded mock interface or separate
mock config file]
Extensions to web.xml
-1: [Web.xml should remain as simple as possible for production, so test
info should go anywhere else, not sure about the ServletRedirector_XXX#
thing, synchronization issues, etc. However, I have no other solution in
mind, so perhaps scale my "vote" to ~0 for "that guy doesn't have a clue"
:)]
Okay, I've voted. I'll return to my regularly scheduled arguing now :).
Please feel free to respond to my other posts as convenient at a lower
priority than support issues and pushing forward on v2. I'm happy with
wherever you go with Cactus v2, but thinking through a lot of different
issues and objections should make you feel more confident about your
direction. Sort of like.... unit testing :).
Tom
