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