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