On Mon, 19 Mar 2001, Vincent Massol wrote:
>
> ----- 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 ?
>
TestActionServlet for the tests that exercise ActionServlet, and so on.
> >
> > 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()
>
You're right, of course. The individual test names should include both
the method being tested and some indication of what you are testing for.
> >
> > > 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/
>
I'm fine with TestXXX_Helper.java, TestXXX_BadConfiguration.xml, and so on
being in the same directory as the test classes themselves, for the
following reasons:
* I have a harder time finding dependent things if they are not
all in the same directory. Because of the common name prefix
(TestXXX), I can tell that all of these things belong together.
* If they are in the same directory, the sorted listing even puts
them all together in a nice order.
> > > 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 ...
Cool.
> >
> > > 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
>
>
Craig
