-
Notifications
You must be signed in to change notification settings - Fork 14k
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
KAFKA-4594: Annotate integration tests and provide gradle build targets to run subsets of tests #2695
Conversation
@ijuma please take a look. New target to run integration tests is |
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.
Thanks for the PR, I had a quick look and left a couple of comments.
A bit unfortunate that @Categories and @RunWith don't work together, but the benefit seems worth it.
maxParallelForks = userMaxForks ?: Runtime.runtime.availableProcessors() | ||
|
||
minHeapSize = "256m" | ||
maxHeapSize = "2048m" |
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.
I wonder if we should reduce maxHeapSize
for the unit tests.
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.
seems fair
build.gradle
Outdated
} | ||
|
||
task testAll(dependsOn: ['test', 'integrationTest']) |
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.
testAll
currently runs all the tests for all Scala versions. So looks like this clashes with that. Could we have unitTest, integrationTest, test (unit and integration for the default Scala version) and testAll (unit and integration for all Scala versions)?
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.
ok - didn't realise that. I'll have a look
|
||
@Category(Array(classOf[IntegrationTest])) |
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.
For the Core tests, could we just annotate ZooKeeperTestHarness
? Seems like that would do the job.
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.
I tried that, but it doesn't seem to like it because it is a Trait
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.
Discussed this offline, seems like we can simply change the traits to be abstract classes. The code compiles fine.
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
@ijuma done |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Thanks for the updates, the overall approach looks good. Can we also update |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
@enothereska, can you please take a look at the changes in the Streams tests? @dguy, there are some conflicts due to a recently merged Streams PR. |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
@@ -0,0 +1,16 @@ | |||
#!/bin/bash |
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.
Why is this script needed?
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.
It's to avoid duplication in various Jenkins jobs. We can just invoke this script and pass any extra parameters (like Scala version).
This seems to indicate we can have both Parametrized and Categories? junit-team/junit4@37a8aab |
@enothereska Great find. I found it too and was happy about it until I noticed that it was only fixed in 4.13, which hasn't been released yet. |
Ok, LGTM, I guess we might have to revisit when Junit 5 comes out, since 4.13 will probably never come out. |
Refer to this link for build results (access rights to CI server needed): |
@@ -892,6 +927,7 @@ project(':connect:api') { | |||
testCompile libs.junit | |||
|
|||
testRuntime libs.slf4jlog4j | |||
testCompile project(':clients').sourceSets.test.output |
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.
@ewencp, are you OK with this and similar changes to the connect test dependencies?
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.
Yeah, I'm not worried about changes in test dependencies.
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.
Thanks for the updates. I had a closer and left a few additional comments. I think it's ready to merge after that.
jenkins.sh
Outdated
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
./gradlew clean compileJava compileScala compileTestJava compileTestScala checkstyleMain checkstyleTest unitTest integrationTest --no-daemon -Dorg.gradle.project.testLoggingEvents=started,passed,skipped,failed $@ |
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.
Can we please add a comment explaining the purpose of the script for other people that came across it?
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.
Also, I think there should be double quotes surrounding $@
. This is necessary in case there are spaces involved.
@@ -116,7 +105,6 @@ public void shouldFanoutTheInput() throws Exception { | |||
streamsConfiguration.put(StreamsConfig.VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass().getName()); | |||
streamsConfiguration.put(StreamsConfig.COMMIT_INTERVAL_MS_CONFIG, COMMIT_INTERVAL_MS); | |||
streamsConfiguration.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest"); | |||
streamsConfiguration.put(StreamsConfig.CACHE_MAX_BYTES_BUFFERING_CONFIG, cacheSizeBytes); |
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.
Did we decide that there's not much benefit in running the test with multiple cache sizes? What is the default cache size?
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.
There is no benefit in this test as it doesn't use the cache at all, i.e., only KTables
use it.
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.
Thanks for the explanation.
@@ -93,9 +90,10 @@ public void before() throws InterruptedException { | |||
streamsConfiguration.put(StreamsConfig.VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass().getName()); | |||
streamsConfiguration.put(StreamsConfig.COMMIT_INTERVAL_MS_CONFIG, COMMIT_INTERVAL_MS); | |||
streamsConfiguration.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest"); | |||
streamsConfiguration.put(StreamsConfig.COMMIT_INTERVAL_MS_CONFIG, 300); |
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.
Seems like this line should be deleted since we have the same config a couple of lines above?
userClicksProducerConfig.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, LongSerializer.class); | ||
IntegrationTestUtils.produceKeyValuesSynchronously(userClicksTopic, userClicks, userClicksProducerConfig, mockTime); | ||
|
||
// |
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.
This may be obvious to others, but for my benefit, why was this code moved?
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.
I'll change it back as it isn't actually needed. Just how i like to see it laid out.
@@ -147,8 +136,8 @@ public void before() throws IOException, InterruptedException { | |||
streamsConfiguration.put(StreamsConfig.STATE_DIR_CONFIG, TestUtils.tempDirectory("qs-test").getPath()); | |||
streamsConfiguration.put(StreamsConfig.KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass()); | |||
streamsConfiguration.put(StreamsConfig.VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass()); | |||
streamsConfiguration.put(StreamsConfig.CACHE_MAX_BYTES_BUFFERING_CONFIG, cacheSizeBytes); | |||
streamsConfiguration.put(StreamsConfig.COMMIT_INTERVAL_MS_CONFIG, 1000); | |||
streamsConfiguration.put(StreamsConfig.VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass()); |
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.
Seems like we have this line twice?
build.gradle
Outdated
testLogging { | ||
events = userTestLoggingEvents ?: ["passed", "skipped", "failed"] | ||
showStandardStreams = userShowStandardStreams ?: false | ||
exceptionFormat = 'full' |
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.
Would it make sense to introduce variables for all these magic values (e.g. "full", ["passed", "skipped", "failed"], etc.)? This way if someone wants to change that, they don't have to change it 3 times (or worse, change it in one place when they meant to change it in every place.
README.md
Outdated
./gradlew core:test --tests kafka.api.ProducerFailureHandlingTest.testCannotSendToInternalTopic | ||
./gradlew clients:test --tests org.apache.kafka.clients.MetadataTest.testMetadataUpdateWaitTime | ||
./gradlew core:unitTest --tests kafka.api.ProducerFailureHandlingTest.testCannotSendToInternalTopic | ||
./gradlew clients:unitTest --tests org.apache.kafka.clients.MetadataTest.testMetadataUpdateWaitTime |
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.
Seems like core:test
is better since if you are running a particular test, you don't care if it's unit or integration? I'd change within a unit test
to within a unit/integration test
in the header instead.
I'd say the same for the Running a particular unit test
section. We can simply say Running a particular unit/integration test
.
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
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.
Thanks, LGTM.
Merged to trunk after tweaking the |
This uses junit Categories to identify integration tests. Adds 2 new build targets:
integrationTest
andtestAll
. Thetest
target will just run the unit tests