+1
We are already using the ant 'junit' task in some of our project, and it
works really well. One thing we have found is that our tests really end up
being split into two kinds: unit, and integration. We classify as 'unit'
those tests which can run on the code as compiled in place in the build
directory. These tests typically stress some smaller piece of code, often
simulating some of the interfaces the code normally interacts with. We
classify as integration those tests which require something to be deployed
into a running server somewhere. While this can and should be automated, it
is a different level of testing... Both kinds of tests are very useful...
> -----Original Message-----
> From: Rob Leland [mailto:[EMAIL PROTECTED]]
> Sent: February 19, 2001 1:37 PM
> To: [EMAIL PROTECTED]
> Subject: PROPOSAL - Testing Framework
>
>
>
> I would like to add some additional Unit tests to the struts
> framework.
> These would be tests for struts itself, not end user code.
> My thoughts are that as struts evolves and new functionality
> is added we want to verify that other functionality is not
> broken, as code is changed and refactored.
>
> I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and
> J2EEUnit (J2eeunit.sourceforge.org). I am going to force
> myself to do this in an upcoming project at work, and believe it
> makes sense to do it in struts also.
>
> I am targeting the 1.1 release time period. If Unit
> testing is approved, some small set of tests may make it into
> the struts 1.0 release, again assuming people here vote for its
> inclusion.
>
> My initial thoughts for providing testing is to start with the
> private methods of struts starting with the
> struts.action package,
> then later develop tests for the public methods of struts.action.
> I didn't want to start another package until I finished the majority
> of the private methods, only because I would need to debug
> my unit tests, and only by developing tests for some of the private
> methods the public could I do this.
>
>
> Then other packages would follow :
> struts.upload,
> struts.util,
> struts.digester,
> struts.actions,
> struts.taglib.X
>
> In about that order, only because that would be a usefull
> order for me
> in the project I am working on. Infact, I only have plans to do
> struts.upload, and
> struts.util, and doubt I would have the time to produce
> tests for the
> other packages.
>
>
> Thoughts ?
>
>
> -Rob
>
