[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpathx-discuss] ANT and JUNIT issues

From: Raif S. Naffah
Subject: Re: [Classpathx-discuss] ANT and JUNIT issues
Date: Tue, 04 Dec 2001 20:18:10 +1100

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.



> which says:

Classpathx-discuss mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]