On Sun, 18 Mar 2001, Vincent Massol wrote:
> 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
>
An implication of this is that the package would be
"org.apache.struts.action", the same as the package you are testing, which
allows access to package private methods. We might want to state that
explicitly as a guideline.
> 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 have a mild preference for "TextXxxxx" -- I think of the word test as a
"verb", and that is what "test xxxxx" would mean (at least in English :-).
I also like naming the test methods "testThisCase()" or
"testThatMethod()" as well.
> 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.
>
+1. This concept should be familiar to Struts developers anyway, because
that is how application resources (message bundles) are accessed.
> 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.
>
(I'm assuming a missing guideline that the tests will be run from an Ant
script of some sort - if that assumption is wrong, the following will not
make much sense.)
Do we really need a TestAll class if we're using Ant to run the tests? We
can easily create targets for each suite of tests you might want to run
together, and have an "all" target that causes all of them to be executed
through appropriate dependencies.
Given that you have to update the Ant testing script anyway as new tests
are added, it seems redundant to also have to modify TestAll.
> 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.
>
> Comments ? (I'm sure I'll get plenty ... :)
>
> Vincent.
>
>
Craig
