Hmmm. Although it does bypass some true integration testing, I think I might
prefer having stubbed logic as well as configuration info drawn from the
web.xml.
the reason: I would not want the added complexity of modifying three
separate files in order to pass an init param to a servlet or filter. There
are some situations where I *would* but init params are relatively simple,
they are not very likely to break from one container to another. Also, since
the proposed web.xml entries would not in fact contain the real mappings to
the components in question (instead containing mappings to the redirector)
the integration test is not 100% integrated. (unavoidable) I agree that it's
valuable to have the additional functionality, I would just like it not to
be mandatory. If I begin suspecting that I need a full integration test to
verify that my values are being read out of the deployment descriptor
correctly, then I would welcome this additional feature. However, I want it
to be optional so that my unit tests are more self-contained.
BTW, the second solution (using cactus.properties for mapping) seems better.
That way test authors are less depndent on a naming convention that could
get quite long.
Cheers,
Nick
-----Original Message-----
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 06, 2001 10:00 AM
To: [EMAIL PROTECTED]
Subject: Re: [proposal/poll] Per testcase configuration of web.xml
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
>
>
>
