[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <bodewig@xxxxxxxxxx>:

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


To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx