You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using JUnit 5's Arguments API performs validation of its parameters at runtime which can lead to three scenarios:
Mismatching types - found when executing the tests (i.e. at runtime).
Insufficient number of parameters - found at runtime.
Definition of superfluous parameters - not found at compile nor runtime.
Description of the proposed new feature
Support a stylistic preference.
Avoid a common gotcha, or potential problem.
Improve performance.
I would like to warn about the following code:
privatestaticStream<Arguments> sumTestCases() {
/* { value1, value2, result } */returnStream.of(
arguments(1, 1, 2), // Correct test case.arguments(
1,
1,
// (1) Wrong type; results in a `ParameterResolutionException`, i.e. runtime exception."Irrelevant parameter"),
arguments(
1,
1,
2,
// (3) Superfluous last parameter does not result in an error.Optional.empty()));
}
@ParameterizedTest// (1) Wrong type; results in a `ParameterResolutionException`, i.e. runtime exception.@EnumSource(java.time.DayOfWeek.class)
// (2) Insufficient number of parameters.@ValueSource(ints = {1, 2, 3})
@MethodSource("sumTestCases")
voidsum(intvalue1, intvalue2, intresult) {
assertThat(value1 + value2).isEqualTo(result);
}
Considerations
(1) and (2) are caught when executing the tests themselves, but (3) is not. Such superfluous parameters result in misleading test cases. Out of the three scenarios, (3) is IMO the one that should be tackled first. However, when adding parameter validation, why only do (3) when the other two are probably not much more work.
Participation
I am willing to submit a pull request to implement this improvement.
I most likely won't get to this in the near future.
The text was updated successfully, but these errors were encountered:
Tnx for filing this issue, @werli! To whomever picks this up: case (3) is not always an issue, since a method source may be used by multiple @ParameterizedTest methods, some that take more arguments than others.
Problem
Using JUnit 5's
Arguments
API performs validation of its parameters at runtime which can lead to three scenarios:Description of the proposed new feature
I would like to warn about the following code:
Considerations
(1) and (2) are caught when executing the tests themselves, but (3) is not. Such superfluous parameters result in misleading test cases. Out of the three scenarios, (3) is IMO the one that should be tackled first. However, when adding parameter validation, why only do (3) when the other two are probably not much more work.
Participation
I most likely won't get to this in the near future.
The text was updated successfully, but these errors were encountered: