commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] Gump failure for "BaseSecantSolverTest"
Date Sun, 26 Jun 2011 15:43:38 GMT
On Sun, Jun 26, 2011 at 01:47:07PM +0100, sebb wrote:
> On 26 June 2011 12:49, Luc Maisonobe <> wrote:
> > Hi Gilles,
> >
> > Le 26/06/2011 13:00, Gilles Sadowski a écrit :
> >>
> >> On Sun, Jun 26, 2011 at 12:41:09AM +0200, Luc Maisonobe wrote:
> >>>
> >>> I think there are some naming conventions. Try using Abstract in the name
> >>> (there are other examples in our tests base) so that gump doesn't attempt
> >>> run it directly.
> >
> > In fact, the proper naming scheme for maven is XxxAbstractTest (see the
> > configuration for maven-surefire-plugin in pom.xml).
> +1
> That also agrees with the Ant build file.
> >>
> >> I can understand that there would be some version difference between tools
> >> run locally and by gump (e.g. the Java version target set to 1.5) but why
> >> would gump have other conventions for picking up test classes than what is
> >> defined in the "commons-math" configuration (supposing everything
> >> necessary
> >> is defined in trunk...).
> >
> > I think Gump relies on ant and Continuum relies on Maven.
> That depends on how the Math Gump project is configured [1]; Gump
> supports both Ant and Maven.
> Gump is currently using Ant for Math.
> So to try and reproduce any errors, use Ant rather than Maven.
> I just tried, and Ant does fail, because it runs BaseSecantSolverTest.
> Whereas
> mvn test -Dtest=BaseSecantSolverTest
> says
> There are no tests to run.

I suppose that this is the behaviour expected by Dennis. It seems logical:
The class is abstract; can this fact be known to the build system (or Junit
or whatever) so that it does not try to instantiate it?
At least, maven's conclusion is correct: It knows that there no tests to run
(or rather that it should not try to instantiate an abstract class) despite
the fact that there are methods marked with the "@Test" annotation.

If it's possible, it is certainly more robust to rely on a Java keyword
("abstract") rather than on an external convention (a name ending with
"AbstractTest"). [Or, more precisely, even if the name does not end with
"AbstracTest", the information exists that can prevent generating an error.]
The introduction of the "@Test" annotation is a progress, going in that
direction; that is, it is not mandatory anymore that the name of a test
method starts with "test". Similarly, it should not be mandatory that a
base class for tests ends with "AbstractTest".

> > Maven also relies
> > on the surefire plugin to run the tests, and surefire relies on Junit. So
> > there are a lot of intermediate steps between a build system (Gump,
> > Continuum, direct use of ant, direct use of Maven, Eclipse, Eclipse with
> > maven plugin ...) and the low level Junit runs. This may explain the
> > differences.
> Indeed.
> > I have already noticed that many tools do not have the same algorithm to
> > select classes to test. A recent example was the performance tests for
> > FastMath. Maven skip these tests because they do not end in "Test", but
> > Eclipse for example does not skip them because it directly look inside the
> > class and find the @Test annotations.
> [Yes, that Eclipse behaviour is a nuisance!]
> It *could* have been that the Ant build file and Maven Pom had
> different configs for the test file names.  However, I've just
> checked, and the files agree.
> The difference is due to the way that Surefire currently processes
> test-classes before handing them to JUnit.

Do you mean that it's Surefire that handles the things correctly?
Then, could it be used also by Gump?

> > There is clearly no ideal solution, but I think having different build
> > systems to suit several users needs is better. Having different tools help
> > finding different bugs.
> Indeed - in this case, the wrong naming convention for an abstract test class.

If it's impossible to properly configure Gump, I'll change the name...


> [1]
> S.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message