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.
> * 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.
> * 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).
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
> 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.
>
> Solution 2a is good because strict and avoid thinking that a test is 100% IC
> when it is not (imagine the situation where I have first written an MO style
> test and then I want to run it in IC mode but I forget to add the init for a
> parameter in web.xml. The test will still run but the parameter will be
> simulated). However, this simply means that we are not testing the passing
> of parameter from web.xml to the container in real and sometimes the user
> will not care to verify this part ... (in which case Solution 2b will be
> preferred) ...
>
> * Warning : Even if MO and IC tests are technically interchangeable, I
> believe that some of the tests will really be interchangeable and some
> others won't simply because it does not make sense ... For example, let's
> imagine I have a method that make use of a domain object. In MO style, I
> will create a mock implementation of this domain object and find a way to
> insert it in my class to test so that it will use this mock object instead
> of the real one. This is because MO are used to test in isolation. However,
> when performing IC tests, I would probably want to use the real domain
> object (to ensure interactions between objects work) ... so in effect I
> would have 2 different tests that are not really interchangeable ...
If "domain object" means an EJB, it could be some trouble. Otherwise, I
see no need for mock domain objects.
> Another example is a database connection. In MO style I may mock the
> database connection and I would be able to run my unit tests on my developer
> machine with no database whatsoever ... In IC test, I might want to actually
> use a test database. If I write this IC test and then try to run it in my
> machine, it will fail ...
Mock Objects were not included in our test setup. All tests went against
a real database -- a test database of course.
> Conclusion: even though IC and MO would be technically interchangeable, all
> tests won't be in practice ... ! :-)
You can see that my point of view is that they should be! But I won't
try to convince you right now, let's wait until you see them running.
Alex.
