----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 18, 2001 11:39 PM
Subject: Re: [PROPOSAL] Struts Unit Test Guidelines
>
>
> 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.
>
sure
> > 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 :-).
What do you propose ?
>
> I also like naming the test methods "testThisCase()" or
> "testThatMethod()" as well.
yes, but testThatMethod() is not enough. For a given method there are
several test cases : one with such bad argument, another with a bad
environment set up, ... So, I 'd rather state it as in 10) below (see
http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) like :
testThatMethodNullPath()
>
> > 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.
>
fine. What about locations of helper classes and resources ? Do we want to
standardize on their naming also. What I do on my projects is to prefix all
of them with the name of the test class that need them. For example :
TestXXX_Helper.class, TestXXX_BadConfiguration.xml, ... But I understand
that you might not like this. The problem is you don't do that you might
find yourselves with tens or hundreds or resources files and classes and you
don' know who is using them. This is especially true if the class to test
use a properties or an xml file. You might want to test your class against
several bad formatted config files to verify that you handle correctly
exceptions cases. Another solution as Martin suggested is to put them
somewhere in conf/test/
> > 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.
yes I agree. Let's forget the TestAll java class. Also, the junit ant task
has a <batch> nested tag to automatically look for classes that extend
TestCase and run them ...
>
> > 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
>
>
>
Vincent
