----- Original Message -----
From: "Jari Worsley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 25, 2001 4:49 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Vincent Massol wrote:
> <snip>
>
> >
> > So, having a correctly behaved MO implementation is not so easy and is
not
> > perfect at all ... Implementing it correctly can be very tricky, may
need a
> > lot of testing (!) and iterations. So in order to be usable, we can
agree
> > that it not _necessary_ to implement it 100% correct the first time and
that
> > you will improve it over time and more importantly that we will need to
run
> > IC tests or functional tests to verify it effectively works.
> >
>
> the old "mock implementation ending up as complex as a real
> implementation" problem eh?
>
kindof
> <snip>
>
>
> >
> > Why not implement a mock (or rather a simple) HTTP server (or simpler
yet, a
> > mock HttpURLConnection that would be used when doing MO tests). The goal
is
> > to have the same architecture for both MO and IC and then the "client"
part
> > of Cactus would stay the same and on the "server" side there will be a
> > factory that will return either real container objects or MO ones ...
Yes,
> > good idea Alex .... :-)
>
>
> there had to be a way to run a Mock object implementation as another
> "container" and that is it - just change the way the connection is
> handled - it just means having different HttpclientHelper classes. If
> you were using the HttpUnit style of client, then you could have
> different subclasses of WebRequest and WebResponse, one to actually
> connect to a container on another machine, another implementation to not
> connect at all, but to stay "in process" and run the mock object
> "container".
>
> I wonder if you would get problems then if people make assumptions about
> how the testcase will be run - i.e. if they assume that client and
> server run in the same address space, then run the test using a real
> container and run into trouble as you now have two address spaces. I
> guess that's why there's been the debate about explicitly denoting which
> tests are in container and which are MO.
>
forget what I said above ... I changed my mind in a subsequent email ... I
agree with what you say. I don't why I said this, it was stupid ... I
thought I had found a good idea ... :-)
> >
> > There is still a problem, it is the IC test initialization data. For a
real
> > IC test, these data would be defined in web.xml ... There is another way
as
> > the one mentionned in my previous email (generation) ... It would be to
use
> > a web.xml file even with MO tests ... Or we could provide 2 ways and the
> > test writer would choose :
> >
> > - either put def. in web.xml and they will be available automatically
> > through the ServletConfig object (be it the real IC one or the MO one)
> > - either call a ServletConfig.setXXX() (but that would mean that for IC
> > tests, the data would not come for web.xml and thus this part of the
process
> > would not be tested but that's only one part of the system so that may
be
> > acceptable).
>
> isn't there something called jxunit that gets data for tests out of an
> xml file? couldn't we do something similar, and have a separate
> "cactus.xml" (or whatever) that acts as web.xml for MO implementation?
> and could also act as configuration for some of the IC tests that need
> servletcontext settings - e.g. when testing a servlet that expects
> certain settings in web.xml.
>
the point is, why reinvent a new format, just use web.xml for MO tests too
then ... so that the same format is used for both IC and MO ...
> >
> > Anyway we need to sort out how we would like to use web.xml for IC tests
> > because we have reached the limits of the current Cactus v1 solution of
> > having a single redirector entry in web.xml ... For example if we wish
to
> > set authentication or have init parameters different for each test case,
we
> > need to be able to define several servlet entries in web.xml (for
example)
> > like ServletRedirector_<testcase name>, which will contain properties
> > dedicated to <testcase name> or something alike.
> >
>
> ah, just replied to this bit totally out of step above.. :). Being able
> to have settings configurable per test sounds like a good thing. and
> leaving the web.xml file alone (especially in some of the more paranoid
> production environments) sounds like a good thing.
We can also allow not to use a web.xml file, as in my proposal. Please vote
.... :-)
>
> > >
> > > 'Functional tests' would be more or less equivalent to 'unit tests in
a
> > > chain'.
> > >
> > > Now, I don't like putting meat inside a servlet. Unit tests apply to
> > > unit functionality, and that should be in different classes. So, I see
> > > all tests done on a servlet as functional -- they apply to many
> >
>
> I'm not sure I like the arbitrary distinctions between unit and
> functional testing. Can any of us actually agree on what the scope of a
> unit test is? Does anyone agree on where unit and "functional" testing
> begin and end? Or is it more useful to think of "testing code using
> other code" - i.e. what tests can you usefully write in source code, and
> what tests do you need to leave to a testing suite (like load testing or
> regression testing)?
>
I have changed my mind slightly on the subject and now consider PF (Pure
Functional) to be a kind of unit test. The functional test would be to
establish a conversation with the server over several calls.
> <snip>
>
> Jari
Please, do vote, as I have made clear proposals (I hope !) for all the
issues above-mentionned ... :)
-Vincent
