The right way to handle this is to adopt a convention and express
that convention in the metadata for the build tools. We did that
early on in math, and that is why you see
<excludes>
<exclude>**/*AbstractTest.java</exclude>
</excludes>
in the junit config in the pom and a similar filter in the Ant
build.xml. So unless we want to change the convention that abstract
test classes have the form above, we should rename the classes.
Phil
On 6/26/11 8:40 AM, Luc Maisonobe wrote:
> 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<luc.maison...@free.fr> 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).
>>>
>>> +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,
> Luc
>
>>
>> Gilles
>>
>>> [1]
>>> https://svn.apache.org/repos/asf/gump/metadata/project/commons-proper.xml
>>>
>>> S.
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
