On 26 June 2011 17:58, Gilles Sadowski <gil...@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-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
