I have just found one limitation with this proposal: the test name has to be
unique for a given webapp ... Whereas in JUnit it only need to be unique in
a TestCase class. Is that a problem ?
Should we update the proposal so the syntax is <prefix>_<class
name>_<testcase name> ? Should we include package name in <class name> ?
[Another solution:]
Or should we rather not formalize the name and instead define which test use
which definition in the cactus.properties file.
For example, in web.xml :
<servlet>
<servlet-name>Default_Config</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>
<servlet>
<servlet-name>Config1</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>
and in cactus.properties :
servletTestCase.* = Default_Config
servletTestCase.my.package.MyTestCase.testXXX = Config1
...
?
By default we would have :
servletTestCase.* = ServletRedirector
jspTestCase.* = JspRedirector
filterTestCase.* = FilterRedirector
which would correspond to the current situation.
It is however slightly more complex as adding a new test that need a new
configuration will mean editing both web.xml and cactus.properties. It will
be probably be interesting only if test initialisation can be factored.
Any other solution ?
What would you prefer ?
Thanks
-Vincent
----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 06, 2001 3:00 PM
Subject: [proposal/poll] Per testcase configuration of web.xml
> 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
>
>
>
