[
https://issues.apache.org/jira/browse/KAFKA-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868584#comment-17868584
]
Chia-Ping Tsai commented on KAFKA-17174:
----------------------------------------
{quote}
I'm also a little insistent on this right now because I'm actively writing,
reviewing, and maintaining the Connect and MM2 integration tests at the moment
and I'll be one of the people absorbing the brunt of the additional workload
incurred by the migration if it drags on and we have an extended period of
fragmentation.
{quote}
{quote}
This would be a breaking change for a lot of external users, and while our
testing API isn't public, I don't think there's a good enough reason to incur
this change, especially since it'd be less convenient even within the scope of
the Kafka project itself.
{quote}
Both reasons are strong and make sense to me. Especially, we assume that
external users relay on the `EmbeddedConnectCluster` to write their tests. Even
though we have a great `ConnectClusterTestExtensions` to allow developers to
have embedded connect service (including underlying breokrs), that still a hard
work to make all external users complete the migration. That means we will
suffer the fragmentation grievously continually.
{quote}
BTW, I think a large pain point here is that it's difficult to compose JUnit
extensions that automatically inject parameters. AFAICT there's no way for,
e.g., a ConnectClusterTestExtensions class to be aware of any ClusterInstance
object that will be automatically injected into a test class/method, and then
leverage that object to bring up its own embedded Connect cluster. Maybe we
could do something to make the ClusterTestExtensions class
inheritance-friendly, so that users could extend that class instead of
annotating their test class with both @ExtendWith(ClusterTestExtensions.class)
and @ExtendWith(ConnectClusterTestExtensions.class)?
{quote}
I feel `ConnectClusterTestExtensions` is a good idea, and IMHO that can a
"interface" of `EmbeddedConnect`. That means developers (and external users)
can use `ConnectClusterTestExtensions` to create a embedded connect service
instead of creating "EmbeddedConnectStandalone`/`EmbeddedConnectCluster`
manually. Also, the impl of ConnectClusterTestExtensions can leverage existent
embeddedxxx class and allow developers to declare service by annotation.
`ClusterTestExtensions` does the similar wrapper on existent
`IntegrationTestHarness`. That means connect module does not to extend
`ClusterTestExtensions`, so `ClusterTestExtensions` keeps
inheritance-unfriendly :smile
> Migrate OffsetsApiIntegrationTest to use ClusterTestExtensions
> --------------------------------------------------------------
>
> Key: KAFKA-17174
> URL: https://issues.apache.org/jira/browse/KAFKA-17174
> Project: Kafka
> Issue Type: Improvement
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Minor
>
> Connect module has its `EmbeddedKafkaCluster`, so another alternative is to
> re-implement it by `ClusterInstance`. However, both of them are a kind of
> "embedded service" interface. Personally, I prefer to unify the interface for
> all modules in testing. We can move any useful helpers from
> `EmbeddedKafkaCluster` to `ClusterInstance` in order to make other modules
> get benefits too.
> `OffsetsApiIntegrationTest` is a lightweight user of `EmbeddedKafkaCluster`,
> so it can be a good entrypoint to introduce `ClusterInstance` to connect
> module
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
