commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [Math] Gump failure for "BaseSecantSolverTest"
Date Sun, 26 Jun 2011 15:40:25 GMT
Le 26/06/2011 17:43, Gilles Sadowski a écrit :
> 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
>>>>> (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?

Some tools are smart enough to detect it, but not all of them.

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

Yes, but it find it after having failed to launch these tests. It does 
not check it beforehand.

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

It would be a good thing, I didn't check if there was a feature request 
on the tools we use for this (ant, maven, surefire, gump, continuum, 
eclipse ...).

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

I don't know all the annotations Junit uses. Perhaps there is something 
for the complete class.

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

It does not handle it correctly, it still tries to launch the tests and 
when it fails, there is an error message.

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

I think this is the better short term solution.

best regards,

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

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

View raw message