>
> 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
