In the current version of Cactus, the configuration of initialisation data
in web.xml can only be done at a global level, i.e. for all test case. For
example, we are able to write :
<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>[...].server.ServletTestRedirector</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>value1 used for testing</param-value>
</init-param>
</servlet>
but then the "param1" parameter will be available to all test cases. What if
we would also like to test that our code also works when no "param1"
parameter is initialised ? It is actually possible to some extent because
there is a "config.setInitParameter()" API available to *simulate* init
parameters from the test case. But the question is still valid, as we might
not want to simulate the parameter but take me from a real web.xml file.
Also, there are other cases where it would be useful to have per testcase
configuration : security configuration, or for selecting filter chains.
I would like to propose the following mechanism (which is backwards
compatible with the existing one) :
* Allow per testcase definitions in web.xml following a defined syntax for
the names : <prefix>_<testcase name>. For example, if we want to have an
init parameter for the XXX test case, we could write :
<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>[...].server.ServletTestRedirector</servlet-class>
</servlet>
<servlet>
<servlet-name>ServletRedirector_XXX</servlet-name>
<servlet-class>[...].server.ServletTestRedirector</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>value1 used for testing</param-value>
</init-param>
</servlet>
* Default to the generic mapping if not per testcase mapping is defined. In
the example above, for the YYY testcase, Cactus will call the
"ServletRedirector" mapping as there is no "ServletRedirector_YYY" mapping.
* The Cactus algorithm is :
1/ Extract the <prefix> from the cactus.properties file. For example if we
have "cactus.servletRedirectorURL =
http://localhost:8080/test/ServletRedirector/";, then the prefix will be
"ServletRedirector"
2/ For each testcase XXX :
a/ Is there a servlet definition for <prefix>_<testcase name> (i.e.
"ServletRedirector_XXX") ?
b/ If yes, call the URL :
http://localhost:8080/test/ServletRedirector_XXX/
c/ If no, call the URL : http://localhost:8080/test/ServletRedirector/
The algorithm will be the same for all redirectors : ServletRedirector,
JspRedirector and FilterRedirector
Let's take the example of filters: Let's imagine I have a filter that adds a
header and footer to a response. In order to test it, I could provide a test
page (/test/test.jsp) and write:
<filter>
<filter-name>FilterRedirector_XXX</filter-name>
<filter-class>[...].server.FilterTestRedirector</filter-class>
<init-param>
<param-name>header</param-name>
<param-value><h1>header</h1></param-value>
<param-name>footer</param-name>
<param-value><h1>footer</h1></param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>FilterRedirector_XXX</filter-name>
<url-pattern>/test/test.jsp</url-pattern>
</filter-mapping>
The only bad thing is that it forces the definition of the test to be in
different locations (in the java test case and in web.xml). However, as
Cactus is specialized for doing integration testing, I don't see any other
means. The other solution would be to provide a stub implementation of the
ChainFilter for the example above but it breaks a bit the idea of
integration testing. Notice that we have already broken it a little by
providing the "config.setInitParameter()" API. This method was provided
before we had this mechanism to define per testcase initialisation
parameters so maybe we could remove it (deprecate it) if we agree on this
mechanism. Or we could leave it ? And even add same kind of stub mechanisms
for everything so that users who do not wish to use web.xml at all could do
it ? My only concern with this is that 1/ it breaks the integration testing
idea and 2/ it is more difficult for new comers what to use as there are 2
options.
Question 1: Would you like to see this per test case mechanism ?
Question 2: Would you like that Cactus always provides alternative
mechanisms that bypasses web.xml (and thus prevent real integration testing)
?
Thanks
-Vincent
