Skip to content

MINOR: Update JUnit to 4.13 and annotate log cleaner integration test#6248

Merged
ijuma merged 6 commits intoapache:trunkfrom
ijuma:junit-4.13
Feb 12, 2019
Merged

MINOR: Update JUnit to 4.13 and annotate log cleaner integration test#6248
ijuma merged 6 commits intoapache:trunkfrom
ijuma:junit-4.13

Conversation

@ijuma
Copy link
Copy Markdown
Member

@ijuma ijuma commented Feb 10, 2019

JUnit 4.13 fixes the issue where Category and Parameterized annotations
could not be used together. It also deprecates ExpectedException and
assertThat. Given this, we:

  • Replace ExpectedException with the newly introduced assertThrows.
  • Replace Assert.assertThat with MatcherAssert.assertThat.
  • Annotate AbstractLogCleanerIntegrationTest with IntegrationTest category.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@ijuma ijuma requested review from ewencp, mumrah and omkreddy February 10, 2019 08:06
@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 10, 2019

#3333 and #3977 were two previous attempts at annotating the log cleaner integration test.

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 10, 2019

Relevant sections of gradle's profile report that take more than 5 seconds:

:core | 1m56.36s | (total)
:core:compileScala | 47.057s |  
:core:unitTest | 38.768s |  
:core:compileTestScala | 29.112s

:clients | 1m18.65s | (total)
:clients:unitTest | 1m10.78s |  

connect:runtime | 48.457s | (total)
:connect:runtime:unitTest | 46.623s |  

:streams | 47.635s | (total)
:streams:unitTest | 40.710s |  

tools | 30.031s | (total)
:tools:unitTest | 28.552s

:streams:streams-scala | 16.430s | (total)
:streams:streams-scala:unitTest | 12.939s |

Copy link
Copy Markdown
Contributor

@ewencp ewencp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of comments, but mostly looks good as it is mostly a mechanical change.

You got my hopes up with this, I've been refreshing the junit 4.13 release issue daily waiting for beta to be approved and released as its final version :)

exceptionRule.expectMessage("ZStandard compression is not supported for magic " + magic);
}
private void assumeV2OrNotZstd(byte magic) {
assumeTrue(compressionType != CompressionType.ZSTD || magic == MAGIC_VALUE_V2);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the shift to checking exact v2 rather than that it is >= if zstd? given our default would be to preserve the feature moving forward, it seems better to write these tests to work for future updates by default (as appears to be the case with the code previously) and only have to edit them if we made a change that wasn't compatible with v2 zstd support.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an oversight, I think I did it right in the other class. Will fix.

public void testFilterToBatchDiscard() {
if (compression != CompressionType.NONE || magic >= RecordBatch.MAGIC_VALUE_V2) {
expectExceptionWithZStd(compression, magic);
if ((compression != CompressionType.NONE && compression != CompressionType.ZSTD) ||
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're starting to use Assume, this seems like it should be one since the condition just skips the whole test?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking the same, but didn't do it in the end. Will change.

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 10, 2019

@ewencp I was refreshing it regularly too and eventually decided that we don't need to wait for it since the rate of change in that branch is nearly 0 and the beta is in the central Maven repo. We'll just bump to final when that happens.

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 10, 2019

JDK 11 build passed, JDK 8 build had one flake:

java.lang.AssertionError:
Expected: <[KeyValue(0, 0), KeyValue(0, 1), KeyValue(0, 3), KeyValue(0, 6), KeyValue(0, 10), KeyValue(0, 15), KeyValue(0, 21), KeyValue(0, 28), KeyValue(0, 36), KeyValue(0, 45), KeyValue(0, 55), KeyValue(0, 66), KeyValue(0, 78), KeyValue(0, 91), KeyValue(0, 105), KeyValue(0, 120), KeyValue(0, 136), KeyValue(0, 153), KeyValue(0, 171), KeyValue(0, 190)]>
but: was <[KeyValue(0, 0), KeyValue(0, 1), KeyValue(0, 3), KeyValue(0, 6), KeyValue(0, 10), KeyValue(0, 15), KeyValue(0, 21), KeyValue(0, 28), KeyValue(0, 36), KeyValue(0, 45), KeyValue(0, 10), KeyValue(0, 21), KeyValue(0, 33), KeyValue(0, 46), KeyValue(0, 60), KeyValue(0, 75), KeyValue(0, 91), KeyValue(0, 108), KeyValue(0, 126), KeyValue(0, 145)]>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at org.apache.kafka.streams.integration.EosIntegrationTest.checkResultPerKey(EosIntegrationTest.java:212)
at org.apache.kafka.streams.integration.EosIntegrationTest.shouldNotViolateEosIfOneTaskFailsWithState(EosIntegrationTest.java:440)

cc @guozhangwang @mjsax

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 11, 2019

@ewencp I've addressed the comments and fixed a few more things I noticed.

Copy link
Copy Markdown
Contributor

@ewencp ewencp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last nit on the version checking in one of the tests, but otherwise LGTM (modulo getting a clean, non-timed-out build)

}

private void assumeV2OrNotZstd() {
assumeTrue(compression != CompressionType.ZSTD || magic == MAGIC_VALUE_V2);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

magic comparison to v2 has same equality change here as in the previous test. any reason not to >=?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for missing this one, fixed.

Copy link
Copy Markdown
Member

@mumrah mumrah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, one small comment inline

Thread.currentThread().interrupt();
expectedException.expect(InterruptException.class);
consumer.poll(Duration.ZERO);
assertThrows(InterruptException.class, () -> consumer.poll(Duration.ZERO));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh wow, this is so much nicer than the rule thing or explicit catches. +1

MemoryRecords records = builder.build();
assertEquals(0, records.sizeInBytes());
assertEquals(bufferOffset, buffer.position());
Supplier<MemoryRecordsBuilder> builderSupplier = () -> new MemoryRecordsBuilder(buffer, magic,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the build method of the builder is what you're testing here, I don't think the Supplier is necessary.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The checks happen in the constructor, right?

if (magic < RecordBatch.MAGIC_VALUE_V2) {
            if (isTransactional)
                throw new IllegalArgumentException("Transactional records are not supported for magic " + magic);
            if (isControlBatch)
                throw new IllegalArgumentException("Control records are not supported for magic " + magic);
            if (compressionType == CompressionType.ZSTD)
                throw new IllegalArgumentException("ZStandard compression is not supported for magic " + magic);
        }

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha. I (incorrectly) assumed the "build" method.

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 11, 2019

retest this please

1 similar comment
@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 12, 2019

retest this please

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 12, 2019

Tests passed, merging to trunk.

@ijuma ijuma merged commit c7f99bc into apache:trunk Feb 12, 2019
@ijuma ijuma deleted the junit-4.13 branch February 12, 2019 06:06
pengxiaolong pushed a commit to pengxiaolong/kafka that referenced this pull request Jun 14, 2019
…apache#6248)

JUnit 4.13 fixes the issue where `Category` and `Parameterized` annotations
could not be used together. It also deprecates `ExpectedException` and
`assertThat`. Given this, we:

- Replace `ExpectedException` with the newly introduced `assertThrows`.
- Replace `Assert.assertThat` with `MatcherAssert.assertThat`.
- Annotate `AbstractLogCleanerIntegrationTest` with `IntegrationTest` category.

Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>, David Arthur <mumrah@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants