On 2018-04-15, Gintautas Grigelionis wrote:
> Moreover, the refactoring of tests is not about extracting repetitive
> code into "smart" methods; it's about parameterizing -- which is
> another nice thing about JUnit 4 -- and we'll be getting to that.
If we could get there with diff smaller than several 1000 lines, I'd
appreciate that. :-)
> 2018-04-15 9:59 GMT+00:00 Stefan Bodewig <bode...@apache.org>:
>> IIRC the fallback would be to use the current working directory instead
>> of the "root" property if the former is not set. We can easily deal with
>> this by using
>> System.getProperty("root", System.getProperty("user.dir"))
>> instead, right?
> Rather,
> System.getProperty("root",
> buildRule.getProject().getBaseDir().getAbsolutePath())
The one case where you removed the root property you switched to using
the one-arg File constructor, so I assumed you needed the current
working directory. Some of the tests using "root" don't use
BuildFileRule right now. But I don't really care how the code gets
adapted as long as it keeps the root property alive and allows you to
run the tests from an IDE.
>> By the looks of it, JUnit 5 runner tests need an assumption check, too.
>> Not sure why, but I may again be missing something.
> Please have a look at TeamCity tests at JetBrains. They start with a
> clean directory, then run ant -Ddest=optional -f fetch.xml, then
> ./build.sh test, and fail with
> java.lang.Exception: No runnable methods
This more looks as if we need an extra dependency for the tests and
should exclude the test class if no engine is present, but I'm not sure.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
