Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[Gintautas Grigelionis]

2018-05-04 8:32 GMT+02:00 Jan Matèrne (jhm) :

> Changing Ants own test to use JUnit5 does not mean we have to change Ant
> itself and don't have to cut a release.
>
> What do you want to move to "ant-legacy"?
>

You're right, JUnit 5 puts no new requirements on Ant.

Should we continue a "legacy" discussion, that would at least include
anything related to J2EE and VCS + deprecated tasks and listeners.

Gintas

Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[Gintautas Grigelionis]

2018-05-05 17:58 GMT+02:00 Stefan Bodewig :

> What is the benefit of changing tests that currently pass when neither
> the test itself nor the code under test is changed?
>

That would be avoiding repetitive code => lucidity.
Eg, for every simple executeTarget("test") there are at least 3 more lines
of boilerplate
(annotation, test method name and braces).
Or, in case of fixture extraction, making sure there are no side effects
from fixture reuse.

Gintas

Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[Stefan Bodewig]

On 2018-05-03, Gintautas Grigelionis wrote:

> 2018-05-03 11:06 GMT+02:00 Stefan Bodewig :

>> I'm still not sure I understand which benefit you see by retrofitting
>> tests that have been written before @Parameterized was invented. They do
>> contain way too many asserts in a single test method, but all of them
>> pass, so this is somewhat moot as long as neither the test nor the code
>> under test is touched :-).

> The benefit is clarity of what is being tested.

This is why I'm totally in favor of using them for new tests or when
adding new testcases to existing tests or when changing code under
test. This has not been my question. :-)

What is the benefit of changing tests that currently pass when neither
the test itself nor the code under test is changed?

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

AW: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[jhm]

Changing Ants own test to use JUnit5 does not mean we have to change Ant itself 
and don't have to cut a release.

What do you want to move to "ant-legacy"?

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Donnerstag, 3. Mai 2018 20:46
> An: Ant Developers List
> Betreff: Re: Parameterized Tests (was Re: ant git commit: Inline
> buildfile names, make search easier)
> 
> IMHO that would mean putting parts of Ant core into ant-legacy.jar
> 
> Gintas
> 
> 2018-05-03 19:03 GMT+02:00 Matt Sicker <boa...@gmail.com>:
> 
> > Yes, I'm definitely suggesting/hyping JUnit 5. :)
> >


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[Gintautas Grigelionis]

IMHO that would mean putting parts of Ant core into ant-legacy.jar

Gintas

2018-05-03 19:03 GMT+02:00 Matt Sicker :

> Yes, I'm definitely suggesting/hyping JUnit 5. :)
>

Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[Matt Sicker]

Yes, I'm definitely suggesting/hyping JUnit 5. :)

On 3 May 2018 at 12:01, Gintautas Grigelionis 
wrote:

> My focus was on maximising the use of JUnit 4 idioms.
> Are you suggesting a switch to JUnit 5 instead?
> Sounds like Ant 1.11 :-)
>
> Gintas
>
> 2018-05-03 17:12 GMT+02:00 Matt Sicker :
>
> > I've started using JUnit 5 in a personal project and found that it has a
> > lot more useful features for test parameters. For instance, they now
> > support parameterized test methods instead of just the class itself.
> There
> > are also more convenient ways of injecting test data through annotations
> > and such. Plus, JUnit 5 still supports v3 and v4 tests, so it's not a
> mass
> > migration effort, either.
>
> --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[Gintautas Grigelionis]

My focus was on maximising the use of JUnit 4 idioms.
Are you suggesting a switch to JUnit 5 instead?
Sounds like Ant 1.11 :-)

Gintas

2018-05-03 17:12 GMT+02:00 Matt Sicker :

> I've started using JUnit 5 in a personal project and found that it has a
> lot more useful features for test parameters. For instance, they now
> support parameterized test methods instead of just the class itself. There
> are also more convenient ways of injecting test data through annotations
> and such. Plus, JUnit 5 still supports v3 and v4 tests, so it's not a mass
> migration effort, either.

-- 
> Matt Sicker 
>

Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[Stefan Bodewig]

On 2018-04-30, Gintautas Grigelionis wrote:

> 2018-04-30 13:13 GMT+00:00 Stefan Bodewig :

>> On 2018-04-30, Gintautas Grigelionis wrote:
>>> the overarching goal, however, is to reduce verbosity, because
>>> verbosity makes it easier to hide mistakes.

>> This is your goal and we should have decided together whether we agree
>> on this goal. The answer seems to be that we don't.

> I get that. What would be the answer if we reduce the scope to
> parameterization of unit tests?

For new tests I'm all for using parameterized test. The same is true
when you add functionality and need to touch the test anyway.

I'm still not sure I understand which benefit you see by retrofitting
tests that have been written before @Parameterized was invented. They do
contain way too many asserts in a single test method, but all of them
pass, so this is somewhat moot as long as neither the test nor the code
under test is touched :-).

This boils down to "make cosmetic changes only when you need to touch
the code anyway", I guess.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Gintautas Grigelionis]

2018-04-30 13:13 GMT+00:00 Stefan Bodewig :

> On 2018-04-30, Gintautas Grigelionis wrote:
> > the overarching goal, however, is to reduce verbosity, because
> > verbosity makes it easier to hide mistakes.
>
> This is your goal and we should have decided together whether we agree
> on this goal. The answer seems to be that we don't.


I get that. What would be the answer if we reduce the scope to
parameterization of unit tests?

Gintas

AW: ant git commit: Inline buildfile names, make search easier

[jhm]

> > In my eyes most of the committers don't like these "code style"
> changes.
> > So please stop these changes and invest your energy more productive.
> >
> > I don't think it would be helpful if another committer starts
> > reverting the changes because of a different preference ...
> 
> 
> With all due respect, please let me know what do you prefer: for
> instance, is test parametrization good, bad or annoying?


For that single point I think parametrization is 'good'.
If I count right, it impacted three test classes.
Why change all the others?

Starting a discussion before such big changes would also be helpful.

Jan





-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Gintautas Grigelionis]

2018-04-30 10:45 GMT+00:00 Jan Matèrne (jhm) :

> In my eyes most of the committers don't like these "code style" changes.
> So please stop these changes and invest your energy more productive.
>
> I don't think it would be helpful if another committer starts reverting the
> changes because of a different preference ...


With all due respect, please let me know what do you prefer: for instance,
is test parametrization good, bad or annoying?

Gintas

Re: ant git commit: Inline buildfile names, make search easier

[Gintautas Grigelionis]

2018-04-30 10:43 GMT+00:00 Jaikiran Pai :

>
> On 30/04/18 12:52 PM, Gintautas Grigelionis wrote:
>
>> My apologies for offending anyone; just one last silly question: why
>> uniformity is not a requirement?
>>
> I think it has already been explained in the other thread why it's not a
> necessity for a project as large and as old as this one, especially when
> the changes aren't solving anything. Plus, I believe you even agreed to it,
> when this was explained in that other thread.
>
> Either way, this isn't about uniformity. Take a look at this commit for
> example (and it's just one of the many). It was done, as you admit, because
> you wanted to find a particular piece of text when you run "grep
> configureProject". There's no level of uniformity that can solve such
> random requirements, unless of course the code is auto-generated to fit in
> these requirements.
>

You're stuck on particulars, grep is just one tool. What I meant is
"searching the code to find relevant information easily", in this case, the
names of buildfiles used in setting up test cases.

Gintas

AW: ant git commit: Inline buildfile names, make search easier

[jhm]

> > Changes like these are random personal preferences.
> 
> Right.
> 
> > The fact that these are being done even after the mail discussions we
> > recently had, indicates that the request to not do such changes have
> > been ignored. This is going down the route of a being some kind of a
> > personal individual hobby project. So I'm just going to stop
> bothering
> > looking into these commits anymore and just stay away from them and
> > stop sending this frustrated and rude sounding mails.
> 
> I must admit I share your frustration and have to thank you for voicing
> it when I didn't dare to do.
> 
> TBH I've given up on giving the changes to tests more that a cursory
> look and hoping "this one is going to be the last one".


In my eyes most of the committers don't like these "code style" changes.
So please stop these changes and invest your energy more productive.

I don't think it would be helpful if another committer starts reverting the
changes because of a different preference ...


Jan




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Jaikiran Pai]

On 30/04/18 12:52 PM, Gintautas Grigelionis wrote:

My apologies for offending anyone; just one last silly question: why
uniformity is not a requirement?
I think it has already been explained in the other thread why it's not a 
necessity for a project as large and as old as this one, especially when 
the changes aren't solving anything. Plus, I believe you even agreed to 
it, when this was explained in that other thread.


Either way, this isn't about uniformity. Take a look at this commit for 
example (and it's just one of the many). It was done, as you admit, 
because you wanted to find a particular piece of text when you run "grep 
configureProject". There's no level of uniformity that can solve such 
random requirements, unless of course the code is auto-generated to fit 
in these requirements.



I believe that even one language that espoused TMTOWDI has moved to
TIMTOWTDIBSCINABTE?
Sorry, I really don't know what that means or how that relates to what 
we are discussing.


-Jaikiran



Gintas

2018-04-30 5:56 GMT+00:00 Jaikiran Pai :


On 30/04/18 11:12 AM, Gintautas Grigelionis wrote:


Names of buildfiles used in tests can be found by "grep configureProject"?


Why is that even a requirement?

I think I am just repeating myself again and again in different mails.
Changes like these are random personal preferences. The fact that these are
being done even after the mail discussions we recently had, indicates that
the request to not do such changes have been ignored. This is going down
the route of a being some kind of a personal individual hobby project. So
I'm just going to stop bothering looking into these commits anymore and
just stay away from them and stop sending this frustrated and rude sounding
mails.

-Jaikiran

The point is that these names are used exactly once, and need not to be put

in a field which is named inconsistently.
Deviations from this rule of thumb indicate that tests are parameterized
in
a manner where each test has its own buildfile.

Gintas

2018-04-30 4:43 GMT+00:00 Jaikiran Pai :

What purpose is this change serving?

-Jaikiran


On 30/04/18 10:08 AM, gin...@apache.org wrote:

Repository: ant

Updated Branches:
 refs/heads/master 0add85310 -> f3dfb7779


Inline buildfile names, make search easier

Project: http://git-wip-us.apache.org/repos/asf/ant/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/f3dfb777
Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/f3dfb777
Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/f3dfb777



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Nicolas Lalevée]

> Le 30 avr. 2018 à 11:58, Stefan Bodewig  a écrit :
> 
> On 2018-04-30, Jaikiran Pai wrote:
> 
>> Changes like these are random personal preferences.
> 
> Right.
> 
>> The fact that these are being done even after the mail discussions we
>> recently had, indicates that the request to not do such changes have
>> been ignored. This is going down the route of a being some kind of a
>> personal individual hobby project. So I'm just going to stop bothering
>> looking into these commits anymore and just stay away from them and
>> stop sending this frustrated and rude sounding mails.
> 
> I must admit I share your frustration and have to thank you for voicing
> it when I didn't dare to do.
> 
> TBH I've given up on giving the changes to tests more that a cursory
> look and hoping "this one is going to be the last one".

Same here.

Nicolas


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Jaikiran Pai]

On 30/04/18 3:52 PM, Gintautas Grigelionis wrote:

2018-04-30 9:55 GMT+00:00 Stefan Bodewig :


On 2018-04-30, Gintautas Grigelionis wrote:


My apologies for offending anyone; just one last silly question: why
uniformity is not a requirement?

Who's uniformity do you pick? There are so many choices that only depend
on taste.

assertEquals(x, y) vs assertThat(y, equalTo(x)) amd many many small
nuances that we all don't need to agree on, as long as we understand
what the code means and does and we accept to not change code just
because it doesn't conform to our own choices.


assertThat(object, matcher) is easier to parameterize, see MakeUrlTest.
And regarding parameterization, I have found at least three cases of
copy-paste errors
where two supposedly different test cases were, in fact, identical.

The assertEquals vs assertThat was an example of different ways a 
certain thing can be implemented. I hope you do realize that what we are 
discussing in this thread (and others) is much more broader than finding 
copy/paste errors due to usage of one API over other.


-Jaikiran

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Gintautas Grigelionis]

2018-04-30 9:55 GMT+00:00 Stefan Bodewig :

> On 2018-04-30, Gintautas Grigelionis wrote:
>
> > My apologies for offending anyone; just one last silly question: why
> > uniformity is not a requirement?
>
> Who's uniformity do you pick? There are so many choices that only depend
> on taste.
>
> assertEquals(x, y) vs assertThat(y, equalTo(x)) amd many many small
> nuances that we all don't need to agree on, as long as we understand
> what the code means and does and we accept to not change code just
> because it doesn't conform to our own choices.
>

assertThat(object, matcher) is easier to parameterize, see MakeUrlTest.
And regarding parameterization, I have found at least three cases of
copy-paste errors
where two supposedly different test cases were, in fact, identical.

Gintas

Re: ant git commit: Inline buildfile names, make search easier

[Stefan Bodewig]

On 2018-04-30, Jaikiran Pai wrote:

> Changes like these are random personal preferences.

Right.

> The fact that these are being done even after the mail discussions we
> recently had, indicates that the request to not do such changes have
> been ignored. This is going down the route of a being some kind of a
> personal individual hobby project. So I'm just going to stop bothering
> looking into these commits anymore and just stay away from them and
> stop sending this frustrated and rude sounding mails.

I must admit I share your frustration and have to thank you for voicing
it when I didn't dare to do.

TBH I've given up on giving the changes to tests more that a cursory
look and hoping "this one is going to be the last one".

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Stefan Bodewig]

On 2018-04-30, Gintautas Grigelionis wrote:

> My apologies for offending anyone; just one last silly question: why
> uniformity is not a requirement?

Who's uniformity do you pick? There are so many choices that only depend
on taste.

assertEquals(x, y) vs assertThat(y, equalTo(x)) amd many many small
nuances that we all don't need to agree on, as long as we understand
what the code means and does and we accept to not change code just
because it doesn't conform to our own choices.

So far the code used to be uniform enough for all other developers of
the code base.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Gintautas Grigelionis]

My apologies for offending anyone; just one last silly question: why
uniformity is not a requirement?
I believe that even one language that espoused TMTOWDI has moved to
TIMTOWTDIBSCINABTE?

Gintas

2018-04-30 5:56 GMT+00:00 Jaikiran Pai :

>
> On 30/04/18 11:12 AM, Gintautas Grigelionis wrote:
>
>> Names of buildfiles used in tests can be found by "grep configureProject"?
>>
> Why is that even a requirement?
>
> I think I am just repeating myself again and again in different mails.
> Changes like these are random personal preferences. The fact that these are
> being done even after the mail discussions we recently had, indicates that
> the request to not do such changes have been ignored. This is going down
> the route of a being some kind of a personal individual hobby project. So
> I'm just going to stop bothering looking into these commits anymore and
> just stay away from them and stop sending this frustrated and rude sounding
> mails.
>
> -Jaikiran
>
> The point is that these names are used exactly once, and need not to be put
>> in a field which is named inconsistently.
>> Deviations from this rule of thumb indicate that tests are parameterized
>> in
>> a manner where each test has its own buildfile.
>>
>> Gintas
>>
>> 2018-04-30 4:43 GMT+00:00 Jaikiran Pai :
>>
>> What purpose is this change serving?
>>>
>>> -Jaikiran
>>>
>>>
>>> On 30/04/18 10:08 AM, gin...@apache.org wrote:
>>>
>>> Repository: ant
 Updated Branches:
 refs/heads/master 0add85310 -> f3dfb7779


 Inline buildfile names, make search easier

 Project: http://git-wip-us.apache.org/repos/asf/ant/repo
 Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/f3dfb777
 Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/f3dfb777
 Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/f3dfb777


>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: ant git commit: Inline buildfile names, make search easier

[Jaikiran Pai]

On 30/04/18 11:12 AM, Gintautas Grigelionis wrote:

Names of buildfiles used in tests can be found by "grep configureProject"?

Why is that even a requirement?

I think I am just repeating myself again and again in different mails. 
Changes like these are random personal preferences. The fact that these 
are being done even after the mail discussions we recently had, 
indicates that the request to not do such changes have been ignored. 
This is going down the route of a being some kind of a personal 
individual hobby project. So I'm just going to stop bothering looking 
into these commits anymore and just stay away from them and stop sending 
this frustrated and rude sounding mails.


-Jaikiran


The point is that these names are used exactly once, and need not to be put
in a field which is named inconsistently.
Deviations from this rule of thumb indicate that tests are parameterized in
a manner where each test has its own buildfile.

Gintas

2018-04-30 4:43 GMT+00:00 Jaikiran Pai :


What purpose is this change serving?

-Jaikiran


On 30/04/18 10:08 AM, gin...@apache.org wrote:


Repository: ant
Updated Branches:
refs/heads/master 0add85310 -> f3dfb7779


Inline buildfile names, make search easier

Project: http://git-wip-us.apache.org/repos/asf/ant/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/f3dfb777
Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/f3dfb777
Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/f3dfb777




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ant git commit: Inline buildfile names, make search easier

[Jaikiran Pai]

What purpose is this change serving?

-Jaikiran


On 30/04/18 10:08 AM, gin...@apache.org wrote:

Repository: ant
Updated Branches:
   refs/heads/master 0add85310 -> f3dfb7779


Inline buildfile names, make search easier

Project: http://git-wip-us.apache.org/repos/asf/ant/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/f3dfb777
Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/f3dfb777
Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/f3dfb777

Branch: refs/heads/master
Commit: f3dfb7779a528439a390ab09383cd8cb6b7e8307
Parents: 0add853
Author: Gintas Grigelionis 
Authored: Mon Apr 30 06:38:27 2018 +0200
Committer: Gintas Grigelionis 
Committed: Mon Apr 30 06:38:27 2018 +0200

--
  .../apache/tools/ant/taskdefs/ExecTaskTest.java |  4 +---
  .../apache/tools/ant/taskdefs/JavadocTest.java  |  6 +-
  .../apache/tools/ant/taskdefs/ParallelTest.java |  5 +
  .../tools/ant/taskdefs/PathConvertTest.java |  4 +---
  .../tools/ant/taskdefs/RmicAdvancedTest.java|  4 +---
  .../apache/tools/ant/taskdefs/SleepTest.java|  3 +--
  .../org/apache/tools/ant/taskdefs/WarTest.java  |  4 +---
  .../tools/ant/taskdefs/optional/ANTLRTest.java  |  4 +---
  .../taskdefs/optional/EchoPropertiesTest.java   | 21 ++--
  .../tools/ant/taskdefs/optional/JavahTest.java  |  4 +---
  .../tools/ant/taskdefs/optional/JspcTest.java   |  4 +---
  .../ant/taskdefs/optional/Native2AsciiTest.java |  5 +
  .../taskdefs/optional/ReplaceRegExpTest.java|  3 +--
  .../taskdefs/optional/RhinoReferenceTest.java   |  3 +--
  .../taskdefs/optional/SchemaValidateTest.java   |  7 +--
  .../optional/XmlValidateCatalogTest.java|  7 +--
  .../ant/taskdefs/optional/XmlValidateTest.java  |  7 +--
  .../taskdefs/optional/depend/DependTest.java|  5 +
  .../ant/taskdefs/optional/image/ImageTest.java  |  3 +--
  .../junit/XMLFormatterWithCDATAOnSystemOut.java |  3 +--
  20 files changed, 25 insertions(+), 81 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/ant/blob/f3dfb777/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
--
diff --git a/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java 
b/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
index fd92ded..cf30955 100644
--- a/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
+++ b/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
@@ -44,8 +44,6 @@ public class ExecTaskTest {
  @Rule
  public BuildFileRule buildRule = new BuildFileRule();
  
-private static final String BUILD_PATH = "src/etc/testcases/taskdefs/exec/";

-private static final String BUILD_FILE = BUILD_PATH + "exec.xml";
  private static final int TIME_TO_WAIT = 1;
  /** maximum time allowed for the build in milliseconds */
  private static final int MAX_BUILD_TIME = 6000;
@@ -60,7 +58,7 @@ public class ExecTaskTest {
  
  @Before

  public void setUp() {
-buildRule.configureProject(BUILD_FILE);
+buildRule.configureProject("src/etc/testcases/taskdefs/exec/exec.xml");
  }
  
  @Test


http://git-wip-us.apache.org/repos/asf/ant/blob/f3dfb777/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
--
diff --git a/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java 
b/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
index f7a287d..cae8620 100644
--- a/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
+++ b/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
@@ -28,13 +28,9 @@ public class JavadocTest {
  @Rule
  public final BuildFileRule buildRule = new BuildFileRule();
  
-private static final String BUILD_PATH = "src/etc/testcases/taskdefs/javadoc/";

-private static final String BUILD_FILENAME = "javadoc.xml";
-private static final String BUILD_FILE = BUILD_PATH + BUILD_FILENAME;
-
  @Before
  public void setUp() {
-buildRule.configureProject(BUILD_FILE);
+
buildRule.configureProject("src/etc/testcases/taskdefs/javadoc/javadoc.xml");
  }
  
  // PR 38370


http://git-wip-us.apache.org/repos/asf/ant/blob/f3dfb777/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
--
diff --git a/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java 
b/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
index eba49c9..c08564e 100644
--- a/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
+++ b/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
@@ -52,14 +52,11 @@ public class ParallelTest {
  /**