----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 6:11 PM
Subject: [Cactus v2 - VOTE] How to make IC and MO tests interchangeable
> Here are propositions for making IC and MO tests interchangeable, i.e. to
be
> able to run a given test case either in MO mode or in IC mode without
having
> to modify it !
>
> Note: During the rest of the mail, we'll assume well' dealing with the
> Servlet API (but the ideas would be the same with JSPs, Taglibs, Filters,
> EJBs, ...).
>
> * 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
> * 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).
>
> All implicit objects stored in XXXTestCase classes will be of that wrapped
> types (i.e. HttpServletRequestWrapper, HttpServletResponseWrapper, ...).
> These wrapper will of course implement the standard API interfaces.
>
+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).
>
+1
> * 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 writt
en
> 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 ...!
>
> 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
> 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 ...
>
> 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 ...
>
> Conclusion: even though IC and MO would be technically interchangeable,
all
> tests won't be in practice ... ! :-)
>
> Apart from that, the premises defined above should lead to tests
> technically interchangeable.
>
> Thanks
> -Vincent
>
-Vincent
