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

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

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.

On 3 May 2018 at 08:10, Gintautas Grigelionis <[hidden email]>
wrote:

> 2018-05-03 11:06 GMT+02:00 Stefan Bodewig <[hidden email]>:
> >
> > 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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> 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 <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> Yes, I'm definitely suggesting/hyping JUnit 5. :)
>
Reply | Threaded
Open this post in threaded view
|

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

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"?

Jan

> -----Ursprüngliche Nachricht-----
> Von: Gintautas Grigelionis [mailto:[hidden email]]
> 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 <[hidden email]>:
>
> > Yes, I'm definitely suggesting/hyping JUnit 5. :)
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Stefan Bodewig
In reply to this post by Gintautas Grigelionis
On 2018-05-03, Gintautas Grigelionis wrote:

> 2018-05-03 11:06 GMT+02:00 Stefan Bodewig <[hidden email]>:

>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

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

Gintautas Grigelionis
In reply to this post by Jan Matèrne (jhm)
2018-05-04 8:32 GMT+02:00 Jan Matèrne (jhm) <[hidden email]>:

> 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
12