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

2018-05-06 Thread 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)

2018-05-06 Thread 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)

2018-05-05 Thread 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)

2018-05-04 Thread 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)

2018-05-03 Thread 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)

2018-05-03 Thread 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)

2018-05-03 Thread 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)

2018-05-03 Thread 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