You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2011/06/26 00:41:09 UTC
Re: [Math] Gump failure for "BaseSecantSolverTest"
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.
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
Gilles Sadowski <gi...@harfang.homelinux.org> a écrit :
Hello.
Thanks to Dennis, the "BaseSecantSolverTest" is an elegant solution for
testing its subclass with the least amount of duplicate code. However, it
doesn't work on the automatic build machine (gump)...
On my machine, it seems to work as expected: The "BaseSecantSolverTest"
class itself is not instantiated (i.e. it is not run when doing "mvn test").
Is it a configuration problem (Junit version, JVM version)?
Regards,
Gilles
_____________________________________________
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Mon, Jun 27, 2011 at 12:09:29AM +0100, sebb wrote:
> On 26 June 2011 17:58, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> >>
> >> 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.]
>
> Yes, because Surefire detects that the class is abstract.
Thus, do you know whether this tool could be used from ant too?
> Did you try "ant test" ?
Not before committing the offending class, if this what you ask.
I usually run "mvn clean site", look at the output of the tests, and at the
CheckStyle-generated HTML page.
> JUnit does not detect it until it tries to run it.
Thus Junit does not analyse the code as Surefire does, but there is an
annotation ("@Ignore") to tell it not to run any tests within the annotated
class. As a side-effect, it does not try to instantiate it.
> >> >
> >> >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.
>
> No. the best option is to use the proper naming convention, so the
> tools don't even try to run the class as a test.
It used to be the only option because the tools were not smart enough. Now
it is not necessary anymore (in the same way that test methods do _have_ to
start with "test").
Before it was necessary, now it's a matter of taste.
> >> >
> >> >>>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.]
>
> Because you are using Maven, not Ant.
Well, I started use maven especially for building commons-math because I was
advised to do so, ant being not well supported (at the time). Did it change?
By the way, I noticed that, in order to run a single test case, the
property definition is not the same with ant and maven:
ant -Dtest.entry=org.apache.commons.math.analysis.solvers.SomeTest test
vs.
mvn -Dtest=SomeTest test
[With ant, the fully-qualified name of the class is required.]
> >> >
> >> >>>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.
>
> Using the correct naming convention is the solution.
It's not _the_ correct solution, it's one solution; using "@Ignore" is now
another which arguably is more robust since the behaviour will be the same,
whatever tool calls Junit, without relying on out-of-band conventions or
intermediate tools.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Luc Maisonobe <Lu...@free.fr>.
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
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by sebb <se...@gmail.com>.
On 26 June 2011 17:58, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>>
>> 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.]
Yes, because Surefire detects that the class is abstract.
Did you try "ant test" ?
JUnit does not detect it until it tries to run it.
>> >
>> >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.
No. the best option is to use the proper naming convention, so the
tools don't even try to run the class as a test.
>> >
>> >>>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.]
Because you are using Maven, not Ant.
>> >
>> >>>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.
Using the correct naming convention is the solution.
>
> 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
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
>
> 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.]
> >
> >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.]
> >
> >>>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
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Phil Steitz <ph...@gmail.com>.
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<Lu...@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-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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Luc Maisonobe <Lu...@free.fr>.
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<Lu...@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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sun, Jun 26, 2011 at 01:47:07PM +0100, sebb wrote:
> On 26 June 2011 12:49, Luc Maisonobe <Lu...@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?
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...
Gilles
> [1] https://svn.apache.org/repos/asf/gump/metadata/project/commons-proper.xml
>
> S.
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by sebb <se...@gmail.com>.
On 26 June 2011 12:49, Luc Maisonobe <Lu...@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.
> 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.
> 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.
[1] https://svn.apache.org/repos/asf/gump/metadata/project/commons-proper.xml
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Luc Maisonobe <Lu...@free.fr>.
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).
>
> 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. 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.
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.
best regards,
Luc
>
>
> 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
Re: [Math] Gump failure for "BaseSecantSolverTest"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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.
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...).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org