New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MINOR: Introduce ApiKeyVersionsSource
annotation for ParameterizedTest
#11468
Conversation
ApiKeyVersionsSource
annotation for ParameterizedTest
@hachikuji What do you think about this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea! LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dajac , thanks for the PR. Left some comments. Thanks.
public class ApiKeyVersionsProvider implements ArgumentsProvider, AnnotationConsumer<ApiKeyVersionsSource> { | ||
private ApiKeys apiKey; | ||
|
||
ApiKeyVersionsProvider() { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Is this constructor necessary?
import org.apache.kafka.common.protocol.ApiKeys; | ||
import org.junit.jupiter.params.provider.ArgumentsSource; | ||
|
||
@Target({ElementType.ANNOTATION_TYPE, ElementType.METHOD}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only applied for ElementType.METHOD
, so ElementType.ANNOTATION_TYPE
can be removed.
5db1d6a
to
3b3f2ae
Compare
@showuon Thanks for your review. I have addressed your comments. |
I will merge the PR as the minor comments have been addressed. |
…Test` (#11468) It is common in our code base to have unit tests which must be run for all the versions of a given request. Most of the time, we do so by iterating over all the versions in the test itself which is error prone. With JUnit5 and ParameterizedTest, we can now use a custom arguments source for this case, which is way more convenient. It looks likes this: ``` @ParameterizedTest @ApiKeyVersionsSource(apiKey = ApiKeys.ADD_PARTITIONS_TO_TXN) public void mytest(short version) { // do smth based on version... } ``` This patch introduces the new annotation and updates `AddPartitionsToTxnRequestTest` test as a first example. I will migrate all the other cases in subsequent PRs. Reviewers: Luke Chen <showuon@gmail.com>, Jason Gustafson <jason@confluent.io>
Merged to trunk and 3.1. |
…Test` (apache#11468) It is common in our code base to have unit tests which must be run for all the versions of a given request. Most of the time, we do so by iterating over all the versions in the test itself which is error prone. With JUnit5 and ParameterizedTest, we can now use a custom arguments source for this case, which is way more convenient. It looks likes this: ``` @ParameterizedTest @ApiKeyVersionsSource(apiKey = ApiKeys.ADD_PARTITIONS_TO_TXN) public void mytest(short version) { // do smth based on version... } ``` This patch introduces the new annotation and updates `AddPartitionsToTxnRequestTest` test as a first example. I will migrate all the other cases in subsequent PRs. Reviewers: Luke Chen <showuon@gmail.com>, Jason Gustafson <jason@confluent.io>
It is common in our code base to have unit tests which must be run for all the versions of a given request. Most of the time, we do so by iterating over all the versions in the test itself which is error prone.
With JUnit5 and ParameterizedTest, we can now use a custom arguments source for this case, which is way more convenient. It looks likes this:
This patch introduces the new annotation and updates
AddPartitionsToTxnRequestTest
test as a first example. I will migrate all the other cases in subsequent PRs.Committer Checklist (excluded from commit message)