Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)
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)
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)
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)
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 : > > > 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)
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)
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)
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 >
Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)
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. On 3 May 2018 at 08:10, 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 perhaps pertains even > more to extraction of fixtures which lead to splitting up of test cases. > Regarding @Parameterized, it is said that it's easier to understand complex > data than complex code. > It's also easier to add new test cases should the need arise, less chance > of missed annotation or copy-pasting a target name. > Call it code churning, but churning actually separates butter from > buttermilk :-) > > Gintas > -- Matt Sicker
Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)
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 perhaps pertains even more to extraction of fixtures which lead to splitting up of test cases. Regarding @Parameterized, it is said that it's easier to understand complex data than complex code. It's also easier to add new test cases should the need arise, less chance of missed annotation or copy-pasting a target name. Call it code churning, but churning actually separates butter from buttermilk :-) Gintas
Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)
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
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
Re: ant git commit: Inline buildfile names, make search easier
On 2018-04-30, Gintautas Grigelionis wrote: > I do realize that some changes might be a subject for discussion; Gintas, please try to see what the others are saying. Most of the changes are changes that nobody of those who've spoken up consider improvements at all - apart from yourself. The outcome of the discussion is pretty clear and this includes changes you don't even consider subject for discussion. > 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. 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
2018-04-30 11:20 GMT+00:00 Jan Matèrne (jhm) : > 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. > Just to pick a nit, there are 9 parameterized test classes. I could easily add another 10-20 classes. But, I'd rather put trivial changes into a separate commit (I remember being told off for mixing in whitespace changes on previous occasions...) Anyway, I also recall that we had a discussion about unit tests which ended up in decision on one detail: any setup details (eg special properties) that can break tests and are controlled by end user must be asserted rather than assumed. The latter should be used for OS- and/or runtime-specific properties. Gintas
Re: ant git commit: Inline buildfile names, make search easier
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
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
Re: ant git commit: Inline buildfile names, make search easier
2018-04-30 10:35 GMT+00:00 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. I do realize that some changes might be a subject for discussion; the overarching goal, however, is to reduce verbosity, because verbosity makes it easier to hide mistakes. If you believe that you might achieve that by another choice, please provide a relevant example. Gintas
Re: ant git commit: Inline buildfile names, make search easier
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
> 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
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
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
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
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
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
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
Names of buildfiles used in tests can be found by "grep configureProject"? 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 >> >
Re: ant git commit: Inline buildfile names, make search easier
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 { /** Standard property value for the fail test