commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [Math] Gump failure for "BaseSecantSolverTest"
Date Sun, 26 Jun 2011 12:47:07 GMT
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 to
>>> run it directly.
> In fact, the proper naming scheme for maven is XxxAbstractTest (see the
> configuration for maven-surefire-plugin in pom.xml).


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.


mvn test -Dtest=BaseSecantSolverTest


There are no tests to run.

> 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.


> 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.

> 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.



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

View raw message