----- Original Message -----
From: "Nicholas Lesiecki" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol" <[EMAIL PROTECTED]>
Sent: Friday, September 07, 2001 4:17 PM
Subject: RE: [proposal/poll] Per testcase configuration of web.xml
> Ok, I had just imagined that you were proposing to apply the the logic to
> init params. I saw your filter example, but since you didn't create a full
> filter chain, I misunderstood it.
>
> I agree that there is definitely an advantage to using the web.xml file
for
> test-case configuration. However, I think that it's also important to
> provide web.xml syntax that mirrors the production environment as closely
as
> possible. A goal I'm sure you're keeping in mind too.
>
> Also, I'm not sure I understand the way you're implementing the Filter
> redirector in the first place, so I'm having difficulty examining your
> proposed options. Could you give amore general explanation?
I'll commit the filter stuff within a few hours (give me 2 hours) so you
could have a look. The idea is the same as for the other redirectors : the
filter redirector is a filter itself. Here is an example of writing a test
for a filter that adds a header and footer to the response. Please note that
the mechanism uses a mock filter chain instead of a real one. The real
mechanism will be to have a test html page or JSP or Servlet and configure
the filter mapping so that it is called, as in :
<filter-mapping>
<filter-name>FilterRedirector</filter-name>
<url-pattern>/somepage.jsp</url-pattern>
</filter-mapping>
This will call the FilterRedirector filter and the next filter in the
FilterChain will be the jsp (I have not tried it but it should work with a
static html too). When we have a per test case configuration (if agreed) it
will be more relevant [which is BTW why I have proposed this pertest case
proposition]
Example:
public void testDoFilterOK() throws ServletException, IOException
{
SampleFilter filter = new SampleFilter();
config.setInitParameter("header", "<h1>header</h1>");
config.setInitParameter("footer", "<h1>footer</h1>");
filter.init(config);
filterChain.setMockFilterChain(new FilterChain() {
public void doFilter(ServletRequest theRequest,
ServletResponse theResponse) throws IOException,
ServletException
{
PrintWriter writer = theResponse.getWriter();
writer.print("<p>some content</p>");
writer.close();
}
});
filter.doFilter(request, response, filterChain);
}
public void endDoFilterOK(WebResponse theResponse)
{
assertEquals("<h1>header</h1><p>some content</p><h1>footer</h1>",
theResponse.getText());
}
-Vincent
>
> Cheers,
>
> Nick
>
> -----Original Message-----
> From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 07, 2001 1:33 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [proposal/poll] Per testcase configuration of web.xml
>
>
>
> ----- Original Message -----
> From: "Nicholas Lesiecki" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Vincent Massol" <[EMAIL PROTECTED]>
> Sent: Thursday, September 06, 2001 9:25 PM
> Subject: RE: [proposal/poll] Per testcase configuration of web.xml
>
>
> > 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.
> >
>
> I'm not 100% sure. However you're taking init parameter as your example
> whereas I was referring to something more generic that would apply to
other
> kind of configuration: security, filter chaining, ... Are you saying that
we
> should provide 2 mechanisms every time (or as much as possible) or are you
> just saying that we should have the 2 mechanisms _only_ for the
> initialisation parameters ?
>
> For filters, the issue is more complex: We need to provide a FilterChain
> object to the filter. This FilterChain is initialized by the container and
> then your filter will call FilterChain.doFilter() to call the next filter
in
> the chain and may process the resulting response. So we have 2 options :
> * implement a wrapper around FilterChain and let the testcase writer pass
an
> output stream that will be returned by doFilter()
> * configure the mapping in web.xml to point to a test JSP that contains
what
> to return.
>
> hum .... my first idea was to provide both mechanisms, then I wanted only
to
> provide the second one and now I'm not sure anymore ... :-) ... My real
> concern is that the more options we leave open the hardest it is for
> testcase writers to decide what to use. But maybe this is good ... ?
>
> > 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.
> >
>
> Let's see what others say ....
> Thanks for your participation.
> -Vincent
>
> > 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
> > >
> > >
> > >
> >
> >
>
>
