----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 23, 2001 8:10 PM
Subject: Re: Servlet Unit Testing strategies
> > Hi Tomcat developers,
> >
> > I'd like to have your opinion on servlet unit testing. I have written a
> > simple extension to JUnit called J2EEUnit to do that but I'd like to
knwo if
> > there is a general consensus on servlet unit testing, regarding it's
> > usefulness :
> >
> > Do you think :
> >
> > 1) It is useless. Just need to put a good facade in front of your
business
> > code and for the remaining part related to Servlets, functional tests
are
> > fine (using a tool such as HttpUnit),
>
> +0.5 I think functional tests ( using HttpUnit or GTest ) are extremely
> important for servlets ( while unit tests are important for beans and
> components used inside servlets ). That doesn't mean unit tests for
> servlets are useless - but that servlets/JSPs shouldn't have a lot of
> functionality, but delegate to beans/ejbs/taglibs that can be unit tested.
I agree, however there are some code, like Controllers, Reverse Proxy, ...
that contains some logic very linked to the Servlet API. Putting a facade
for these are quite cumversome because they manipulate a lot of Servlet
objects and writing a facade means a lot of marshalling / methods ... But I
agree that most of the code can be unit tested independently of a servlet
context ...
>
> Also, I think that for tomcat testing ( i.e. the container ) functional
> tests are more apropriate and efficient, and easier to write ( but doesn't
> mean we shouldn't have unit tests for individual components ).
>
> > 2) It is nice to be able to unit test the part of the code related to
> > servlets (i.e. the controller in a MVC model).It is possible to come up
with
> > a tool to do that (ex: J2EEUnit)
>
> I'm not sure I understand this - but any test is nice as long as it's easy
> enough to write.
>
It simply means that within the framework you can separately call methods
that require access to valid HttpServletRequest, HttpServletResponse,
HttpSession, ServletConfig, ... objects
>
> > 3) With the current servlet API it is not possible to come up with a
> > framework that will let you properly do unit tests. It will have lots of
> > shortcomings. The only solution is to extend the Servlet API by our own
> > Servlet Test API. Then have Tomcat implement it. Once we have this, it
will
> > then be possible to create a tool/framework that make use of this Test
API
> > to unit test servlet. The next step will to promote this API so that it
> > becomes a standard and other Servlet engine implement it.
>
> -1. Extending the servlet API or implementing any extension in tomcat is
> not an option, and a test framework that requires changes in the design or
> implementation of the tested application is _bad_.
>
> It doesn't matter how good the test framework is, if you have to change
> your code to use it it's not good enough.
>
> ( IMHO )
>
2 points here :
1) I did not mean changing the Servlet API ... I meant, make it easier for a
testing framework to be able to unit test servlets/Filters/Taglib/... by
offering a helper API. For example, the JVMPI offers an API that ease
writing profiling tools but it does not change the Java language. I meant
more a helper framework on the container side, not on the servlet API side.
2) For any test framework that you use, you may have to modify your own
class to help testing it ... but this is not bad, this usually brings a
better design ... For example : let's say you have a class that uses a
Properties file to read some data. Let's imagine you want to test your class
that reads it and retrieve some properties. If you want to test all the
cases, you have to provide several versions of this properties file : some
with incorrect values, undefined properties, ... It means that even if you
don't need it, you may have to add a setPropertiesFileName() to your class
so that when you write your test class you can use the different test
properties file, ...
> Costin
>
>
Thanks a lot for taking the time to answer.
Vincent.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
