----- Original Message -----
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2001 7:52 AM
Subject: Re: [PROPOSAL] Struts Unit Test Guidelines
> Please see comments inline.
>
> ----- Original Message -----
> From: "Vincent Massol" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, March 17, 2001 11:51 PM
> Subject: [PROPOSAL] Struts Unit Test Guidelines
>
>
> > I think we need to give some guidelines for anyone who would like to
> > participate in writing unit tests for Struts. I'd like to start this
> process
> > by giving you my views on the subject and discuss it. When we have a
final
> > agreement, we can put a web page on the struts web site.
> >
> > Here are some of the rules/guidelines that I can see so far :
> >
> > 1) Put the test sources in jakarta-struts/src/test. For example if you
> want
> > to write a unit test for class org.apache.struts.action.ServletAction,
you
> > woud put the test class in
> jakarta-struts/src/test/org/apache/struts/action
>
> I had been thinking of a "sub-package" for tests (e.g.
> <original-package-name>.test), but now that I think about it, it makes
sense
> to put the tests in the same package, for access reasons.
>
> > 2) Name of the test class. For any XXX class to test, the associated
test
> > class should be named TestXXX. I'm sure others will prefer XXXTest. I
> don't
> > really care, we just need to standardize on one.
>
> I would prefer TestXXX, for two reasons:
>
> 1) It matches the way I think about unit tests ;-) (i.e. "test this,
> please")
> 2) It is consistent with JUnit's automatic identification of tests using
> testXXX() methods.
>
> > 3) Any helper class and resources for the test should be put in the same
> > directory as the test class. For example, if my test class accepts
several
> > xml files, I would put them where I put my TestXXX class and I would use
> > Class.getResourceAsStream() to load them (thus removing the need to hard
> > code the path of the resource). Again, this is a proposition. Another
> > solution would be to put them in the jakara-struts/conf/test directory.
>
> When I was thinking about "sub-packages" for testing, I had been thinking
> about a ".testdata" sub-package. I still think a separate package for test
> data would be useful. It would help isolate data used as input to the
tests
> from data required by the test code itself, and isolate both of those from
> data in the package under test.
>
Why not, but then it must be unique enough so that this package does not
exist in the src packages ? Or put the helper classes in the same dir and
helper config files in conf/test ?
> My thinking is that test data for the
org.apache.struts.action.ServletAction
> class would be found in
> jakarta-struts/src/test/org/apache/struts/action/testdata/.
>
> I agree completely with using Class.getResourceAsStream() to access the
test
> data. That's what I'm doing now. :-)
>
> > 4) All test suites should be gathered in a single TestAll.java (or
> > AllTest.java) test class that will located in
> > jakarta-struts/src/test/org/apache/struts. The build.xml target for unit
> > tests will use this file to run all the tests.
>
> To the extent that this can be done automatically, I agree. However, I
think
> we should do as much as possible to minimize the effort required to add a
> new test.
>
> For example, with JUnit, you can add a test just by adding a method named
> "testXXX" to your class derived from TestCase. If we can define a Struts
> test suite in a similar way, perhaps using JUnit constructs or perhaps
using
> Ant build files (which are probably more flexible), that would be great.
>
yes I agree. See my response to Craig's email on the same subject
> > And then general good practice rules (See this article for more details
> > http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) :
> >
> > 5) Test cases should be completely independent from one another. Don't
> > assume the order in which your test cases will run.
> > 6) Avoid hard coding paths in your test cases
> > 7) do not use the test case constructor to set up a test case
> > 8) Avoid writing test cases with side-effects
> > 9) Keep tests small and fast
> > 10) Name test cases properly
> > 11) Ensure that tests are time independent
> > 12) Consider locale when writing tests
> > 13) Always test for error conditions
> > 14) Utilize properly assert/fails and exception mechanism (i.e. don't
put
> a
> > ty/catch around a test case for which you don't expect an exception)
> > 15) Document tests in javadoc. This is very important as unit tests are
a
> > very good way to document the code.
>
> These seem like good guidelines to me!
>
> > Vincent.
>
> --
> Martin Cooper
>
>
>
>
Vincent
