I like this as a baseline integration test. We should consider what set of happy path dimensions we want to validate here and if test parameterization or extension here would help with testing coverage.
In particular, I think there's a number of implicit decisions here: which converter is being tested, there are no transformations, that the default integration test uses distributed mode (and therefore specific offsetwriter, config source, etc), we're using connector overridden converter settings, which data types are used in the records, etc. There's always going to be a fair bit that is explicit, but some of this may be worth deciding whether to specifically test here, and to get coverage in a smaller number of tests. In particular, things like covering many/all data types and including testing of transformation functionality are things I think we should probably try to include in a single test. Our experience elsewhere with these heavyweight "integration" tests which actually also pull up external services rather than mocking them is that they get very expensive, very fast, and that's part of why I avoided adding them for Connect initially. I think if we're doing these expensive "local system test" version of integration testing, we should try to write fewer more comprehensive tests. As another example, this test could also validate various REST API functionality once the connector is submitted. This covers a bit of it with the create/delete, but we could also validate, e.g., the status APIs. [ Full content available at: https://github.com/apache/kafka/pull/5516 ] This message was relayed via gitbox.apache.org for devnull@infra.apache.org
