Re: [Classpathx-discuss] ANT and JUNIT issues

[Raif S. Naffah]

At 10:20 PM 12/3/01 -0500, Andrew Selkirk wrote:
> On December 3, 2001 05:35 am, Raif S. Naffah wrote:
> > At 09:37 AM 12/3/01 +0000, Nic Ferrier wrote:
> >
> >        <java classname="test.AllTests"
> >              fork="yes" taskname="junit" failonerror="true">
> >           <classpath>
> >              <pathelement location="${test.jar}"/>
> >              <pathelement location="${main.jar}"/>
> >              <pathelement location="${junit.jar}"/>
> >           </classpath>
> >        </java>
> >     </target>
>
> Question for ya.  I've wondered the necessitiy of the AllTests test suite
> class in a junit/ant system.  Instead of hard coding all the tests in a class
> creating a point of failure, I find it much more useful to use ANT's power to
> search for all the tests and execute them.  I use a standard naming
> convention on them so they are easy to find.  I also allow a runtime property
> if you want to dynamically generate a subset test suite:
>   ant test -Dtest=event
> The test property (if is exists) provides a filter on the directory structure
> since the packages in a class namespace are generally unique.
>
> Have you found the same?  Thoughts?

to tell you the truth, i was so enthralled by the mere existence of junit 
that i started using it _almost_ religiously!

when i started using junit, i was using make for the build.  at the time it 
was more natural/effective to just:

(a) create a parallel test hierarchy with almost similar tree structure as src.
(b) follow the AllTests pattern; ie. put an AllTests in each subtree that 
gets called by the one in the parent directory.

does it still make sense?

well... if you know that your users will always use ant, you then have a 
choice: follow a pattern that does not rely on ant, or use ant's power and 
with a minimal set of conventions as you suggest you can replicate the 
call/invocation flow.  on the other hand if you assume that your users 
might not use ant just because you have included a build.xml, and instead 
run some other tools, like autoconf/automake, it's then safer to follow the 
junit accepted/expected pattern.

* today ant is _not_ the only way to build java projects;
* the junit framework may evolve and offer more flexibility, if we start 
shunting it we might be losing, its future added features/benefits, in the 
long run.
* i'm not sure what you mean by a point of failure.  i see a plus in having 
the pattern: a directory (sub-package) AllTests calls specific tests in the 
class itself and AllTests in subordinate sub-packages.  extend this pattern 
to things like AllTestsJDK1 and AllTestsJDK2, etc... and you have trees of 
tests that you can easily build+invoke.  i find it simple, extensible and 
effective.
* i like your idea of conditioning the execution of tests based on a 
property setting.  this goes very nicely with what i was suggesting earlier 
in terms of AllTestsFoo, AllTestsBar, etc.  but... i believe that _every_ 
distribution should have a _minimal_ set of tests it should pass _before_ a 
deliverable can be packaged/released.  this minimal test may not be a junit 
one, but i'm sure with a bit of effort it can become one.  the _default_ 
AllTests may be just that.
* re. naming.  i'm happy with the junit default behaviour of introspecting 
the test classes and finding out the method names, and i do use 
that.  other than that, i prefer to explicitely set the test classes in the 
AllTests of each sub-package.


cheers;
rsn


> Andrew...
>
>
>
> >
> > which says:
>
> _______________________________________________
> Classpathx-discuss mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpathx-discuss