Alex Fern�ndez wrote:
>
> Again, a bit late.
>
> Vincent Massol wrote:
> > * Premise 1 : All HTTP parameter initialization (Cookies, HTTP headers, HTTP
> > parameters, HTTP method (GET, POST,..), ... will need to be initialized in
> > beginXXX() for all kind of tests (MO, IC, PF).
>
> +1.
>
> But I remember Thomas' mail that you needn't do this. In fact, it's a
> bit of a PITA, but it's coherent.
+1
it's also consistent with the idea of container testing in general - the
fact that if you are testing a container from the outside, then you are
testing over a network protocol. So the fact you have a client and a
server relationship when doing in container testing means you are likely
to need client side setup code as well as the server setup code.
>
> > * 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. For
> > example, there need to be a
> > "ServletConfigWrapper.setupAddInitParameter(String name, String value)" to
> > add an init parameter that would normally have been defined in web.xml. This
> > is also to override existing container behaviours (like
> > HttpServletRequest.getRequestDispatcher(String relativePath) that need to be
> > overriden to take into account the WebRequest.setURL() values).
>
> +1.
>
+1
and when using the servlet 2.3 spec there are a number of Wrapper
classes defined already! - what a bonus :)
> > * 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
> > mechanism (see next email for proposition on how to do this).
>
+1
see one of my other mails but yes, extending the init method is good.
Having code based control and declarative XML based control is even
better :). Meaning - allow code to restrict what containers it allows
itself to be run in, so some tests which would expect to pass IC and MO
will allow both. Other tests or even individual testmethods may restrict
themselves to just IC. Then in the config file determine what container
you are using at the current time, and settings for the containers you
wish to use.
> Don't know, we'll see then.
>
> > * Premise 4 : What happens when cactus encounters a
> > "ServletConfigWrapper.setupAddInitParameter(String name, String value)" call
> > in testXXX() and when in IC mode ? Indeed, this is how tests will be written
> > in MO mode, so if we don't touch the code, it will also be executed in IC
> > mode.
> >
> > Premise 4, Solution 1 : Force MO tests to define init data in a web.xml file
> > in the same way that IC tests do. This is a bit more cumbersome to write but
> > is consistent with IC tests. Persons who only wish to write MO tests (No IC
> > tests) will find this a PITA though ...!
>
> +1.
>
> Yes, it is. But it's a one-time item, though.
>
> I'll tell you how we did mock-servlet testing: the init() methods took
> the ServletConfig and looked for the necessary parameters, in fact only
> one: the directory where the rest of the config files were (a Un*x
> directory).
>
> If there was no init parameter, then a default one (a c:\ Windows
> directory) was chosen.
>
> This was not an optimum solution, but it saved us the trouble of parsing
> a web.xml file in the mock objects. However, if you must have a web.xml
> anyway, for production use, it may be worth it: you just modify it for
> tests.
>
> > Premise 4, Solution 2 : Apply the following algorithm when in IC mode :
> >
> > - if the config data is already defined (i.e. it has already been defined in
> > web.xml), then ignore the call to
> > "ServletConfigWrapper.setupAddInitParameter(String name, String value)". If
> > not, then :
> >
> > Premise 4, Solution 2a : raise an exception saying that the parameter should
> > have been defined in web.xml
+1 - I like strict :) definitely throw an exception - after all, in
this case, all the test writer needs to do is move the offending method
call into the "beginXXX" method for the testcase.
> > Premise 4, Solution 2b: save the parameter value as in MO mode. Meaning that
> > the corresponding getter will return this mocked parameter instead of a real
> > one coming from web.xml.
> >
<snip>
Jari
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
