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
