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?
<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.
>
> 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.
>
> 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.
> >
> > '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)?
<snip>
Jari
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
