----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: "Vincent Massol" <[EMAIL PROTECTED]>
Sent: Monday, July 16, 2001 8:04 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Vincent
>
> "Have a single framework for
> implementing all unit tests for server-side java code. Instead of having
to
> learn and use 3 or 4 different ones."
>
> I would argue that what you are doing by having separate base classes for
IC
> and MO is, in effect creating two frameworks that just happen to exist in
> the same package. Is this is a bad thing? I do not know. Question of
Yes, but you only need to download, install and read the doc. for a single
framework.
> curiosity: Do you personally create two separate test classes for unit and
> functional tests on the same class?
>
Yes.
> "You don't _have to_ maintain 2 testing code bases. Meaning that you can
> choose to do only MO style test if that's enough for you."
>
> If I were only choosing to do MO testing, why would I use Cactus? Why
would
> I not just use jUnit and spin my own mock objects or use the ones that
Alex
> posted awhile back? As I understand it, there is no need for the
beginXxx()
> and endXxx() methods when using mock objects. Am I wrong?
>
That would be an option for you of course. However Cactus will provide a
single place where to look and will contain full range MO implementation for
all J2EE APIs. Maybe Alex will only provide for Servlet API and maybe he
will not cover all APIs of the spec. 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. The idea is to create this ... :)
Now, I have sent an email to the guys doing the Sourceforge mockobject
project (see
http://sourceforge.net/forum/forum.php?thread_id=121222&forum_id=57634).
Very quickly, the idea might be to start a new project on Jakara-Commons
(provided this is accepted) that will a reference place for MO
implementations. Then make Cactus use it internally. Cactus would be the
umbrella project. Person who want nice doc., a single place where to look
at, a unified way of writing different kind of test cases, ... would use use
Cactus. People who would wish to use only "raw" MO may not use Cactus ...
But don't forget that MO is not the panacea either ...
These are just ideas I am throwing ... :-)
> This is a good discussion and is stimulating some new thinking, at least
> over here. I hope you do not feel hen-pecked because it is certainly not
my
> intent :).
>
Not at all. I actually like this discussion and I really appreciate your
taking the time to participate. Remember that Cactus now belongs to all of
us. That happened when I donated it to the Jakarta project. Sometime, my
tongue slips and I lapse into a "I" instead of "We" and I do apologize for
that.
Remember that nothing has been committed yet for Cactus v2 so we are free to
change everything still to make it a better framework. I have actually began
thinking again on how to have a single TestCase base class. This is not the
real issue. We can very easily have a single CactusTestCase class.
Here are some brainstorming ideas / issues / questions :
1/ How do you tell a test case which kind of test it should run : There are
3 types : IC, MO and pure functional. Is this choice done inside the test
case by calling an API or externally like in a XML or properties file where
you have all your tests listed as in :
com.my.MyTestCase1.testXXX1 = MO
com.my.MyTestCase1.testXXX2 = IC
...
com.my.MyTestCase2.testXXX1 = PF (Pure Functional)
...
2/ 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. Switching a test
from MO to IC would mean defining a servlet redirector URL (in the
properties file mentionned above for instance). This is do-able. Now PF is
another beast entirely and it would not mean anything to switch it from PF
to MO or IC I think.
3/ In order to be able to switch from MO to IC (or vice-versa), you need to
able to use the same implicit object APIs. These APIs are richer for MO as
in IC lots of init data come from web.xml. Several options :
a/ Simply ignore the MO APIs that have no meaning under IC when switching
from MO to IC and provide the equivalent in the web.xml. It means that the
test could fail if these init. data are "forgotten" in web.xml. Also it does
not work better the other way round, from IC to MO as you have to add some
code to init. MO implicit objects
b/ The idea I was toying with but which is slightly complicated :
generation. Meaning, there is a single uniform way of init. implicit objects
(a la MO style, i.e. providing setters for all init. on implicit objects).
This runs fine when doing MO tests. When doing IC style, Cactus would
generate a web.xml file containing the correct definitions and ignore the
setters on implicit objects that are already initialized by the web.xml
file. It is a variation to a/ but you don't have to worry about the web.xml,
which is good ! The problem is that the web.xml file need to generated on
deployment whereas cactus runs at runtime ... :( So we would need a first
framework part that would take generic test cases (using MO like conventions
for writing it) and which would generate either MO, IC or PF test cases.
This first framework part would be run (using Ant for instance) and produce
the classes that will be run in the second (runtime) part of the framework
(using JUnit).
Solution b/ is probably the best but introduces some complexity. If you
think about it further it simply means that we will invent a new way of
defining a generic test case (we could it graphically, using XML, in a new
scriptiong language, using JUnit-like test cases, ...) and we would
_generate_ and maybe _package_ the real tests that would be run. It menas we
would be adding a new layer before JUnit tests, in the same way that
TestMentor from Silvermark does for instance (cf
http://www.silvermark.com/ - it is an test IDE that can generate or run
JUnit tests). BTW, I have had some discussions with Silvermark and they are
integrating Cactus within their tool so that it can run cactus tests too
(not too difficult seen that cactus tests are junit tests).
However as I said in a previous email, I don't like much generation and
would prefer to do without if possible ...
Hope I have stimulated new ideas / chain of thoughts ... :)
> Tom
-Vincent
