commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [Math] Gump failure for "BaseSecantSolverTest"
Date Sun, 26 Jun 2011 17:08:48 GMT
Le 26/06/2011 18:58, Gilles Sadowski a écrit :
>>
>> 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.
>
> How do you see that?
> When I run "mvn test" here, the output does not show "BaseSecantSolverTest"
> at all, and the build is successful. [Otherwise I wouldn't have committed
> that class.]

Sorry, I was confused by another message, my bad.

>
>>>
>>> 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.
>
> I'll check whether instanitation could be disabled at that level; that would
> indeed be the best option.
>
>>>
>>>>> 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.
>
> Then I don't understand why it works locally, but not on the build server...
> [No error message here.]

This build server is configured to use ant for now.

Luc

>
>>>
>>>>> 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.
>>
>
> Probably, if there is no Junit annotation.
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message