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.
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.
> 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
