----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol" <[EMAIL PROTECTED]>
Sent: Sunday, July 15, 2001 10:21 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Vincent
>
> "You're right is wasn't mentioned. My initial goal was to have for example
a
> single ServletTestCase class that could be used for both MO and IC.
Thinking
> about it, I have found 2 things... Now I am interested by your thoughts on
> this."
>
> I agree with Russell - if it requires base class specialization, then
> perhaps it is best to dump the MO entirely and continue to focus Cactus on
> in-container testing, so I shall await your response to him before
> commenting further. One minor suggestion if you go ahead with MO is to
name
> the in-container base classes without the "IC" prefix. If you decide to
back
> out the MO later on, you do not have to explain why your standard base
> classes are named "IC*".
>
> "Yes, you are right about the 2 sets of classes (IC and MO tests)."
>
> I am more in favor of dropping MO entirely. Maintaining two testing code
> bases for a project is just too complicated and fraught with error.
>
If you look at Cactus implementation of servlet in-container testing you'll
see that it has now reached a wall. I already see requests to provide
Servlet API support that it cannot continue to do in an IC manner, or very
difficult (like security and credential stuff). You'll also see that a few
methods are already implemented in a mock style way because I couldn't find
ways of implementing them the IC way ... For example :
ServletContext.getServletName(),
HttpServletRequest.getRequestDispatcher(String relativePath) and a few more.
It would be possible (up to a certain extent) to implement them in an IC way
but that would lead to a solution that would make writing test case too
painful (like having to provide a servlet entry in web.xml for each test
case, ...).
This is just to tell you that if we want Cactus to be more useful (and I
think we will and I certainly will) we need to allow for MO when it is
useful to do so. Again the main advantage is : 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.
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. Or do 80% MO and
provide 20% IC just to confirm that it works when deployed. Or only do 100%
Cactus tests because you don't need fine grained unit tests.
Still, even if I want to do 80%/20% MO/IC I prefer to do it by writing test
cases using the same framework that having to learn 2 frameworks.
-Vincent
