10000 KAFKA-18332: fix ClassDataAbstractionCoupling problem in KafkaRaftClientTest(1/2) by leaf-soba · Pull Request #18926 · apache/kafka · GitHub
[go: up one dir, main page]

Skip to content

KAFKA-18332: fix ClassDataAbstractionCoupling problem in KafkaRaftClientTest(1/2) #18926

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

Merged
merged 14 commits into from
Apr 17, 2025

Conversation

leaf-soba
Copy link
Contributor
@leaf-soba leaf-soba commented Feb 17, 2025
  • extract a unit test named KafkaRaftClientClusterAuthTest to reduce the number of imported class

Reviewers: Chia-Ping Tsai chia7712@gmail.com

remove unnecessary public
remove unnecessary `toString`
checked all changed list in this class are immutable
extra the method in the assertThrows
rename record to expectedRecord
use a loop instead of repeated code
extract a unit test named KafkaRaftClientClusterAuthTest to reduce the number of imported class
@github-actions github-actions bot added triage PRs from the community tests Test fixes (including flaky tests) kraft labels Feb 17, 2025
@leaf-soba leaf-soba changed the title KAFKA-18332: fix ClassDataAbstractionCoupling problem in KafkaRaftClientTest KAFKA-18332: fix ClassDataAbstractionCoupling problem in KafkaRaftClientTest(1/2) Feb 17, 2025
@leaf-soba
Copy link
Contributor Author
leaf-soba 10000 commented Feb 20, 2025

Hi @ijuma, @chia7712, @gongxuanzhang, could you please take a look?

Copy link

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.

Copy link
Member
@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

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

@leaf-soba thanks for this improvement. one small comment is left

@@ -4641,15 +4533,15 @@ public void testHandleLeaderChangeFiresAfterResignRegistration(boolean withKip85

@ParameterizedTest
@ValueSource(booleans = { true, false })
public void testObserverFetchWithNoLocalId(boolean withKip853Rpc) throws Exception {
Copy link
Member

Choose a reason for hiding this comment

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

could you please revert those unrelated changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've reverted the unrelated changes. Let me know if there's anything else that needs adjustment. Thanks!

revert remove unnecessary public
@leaf-soba leaf-soba requested a review from chia7712 March 1, 2025 08:50
@github-actions github-actions bot removed triage PRs from the community needs-attention labels Mar 2, 2025
@@ -359,7 +356,10 @@ public void testInitializeAsResignedLeaderFromStateStore(boolean withKip853Rpc)
assertEquals(0L, context.log.endOffset().offset());
context.assertElectedLeader(epoch, localId);
context.client.poll();
assertThrows(NotLeaderException.class, () -> context.client.prepareAppend(epoch, Arrays.asList("a", "b")));
// Only one method invocation is expected when testing runtime exceptions
Copy link
Member

Choose a reason for hiding this comment

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

Pardon me, I don't catch the point of this change. Is it a refactor about code style?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for your comment.
the original code:

assertThrows(NotLeaderException.class, () -> context.client.prepareAppend(epoch, Arrays.asList("a", "b")));

In this case, there are two method calls inside assertThrows:

  1. prepareAppend
  2. Arrays.asList

I believe it’s generally a good practice to keep the tested code as clear as possible by avoiding multiple method calls within assertThrows. While Arrays.asList would never throw a NotLeaderException, separating it slightly improves the readability of the test.
I understand if this change is unnecessary. Please let me know if you’d prefer me to revert it.

Copy link
Member

Choose a reason for hiding this comment

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

Thank you for sharing all of this. We prefer to keep this PR focused on fixing only what's necessary. Other improvements can be addressed in a follow-up if needed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@chia7712 Thank you for your feedback! I have reverted the unnecessary change related to throwing two exceptions in one assertThrows.

There are still some other minor improvements—would you prefer that I revert all of them in this PR, or should I keep them and address them in a follow-up PR instead? I'm happy to proceed in whichever way aligns best with the project's approach.

revert extra the method in the assertThrows
@chia7712
Copy link
Member
chia7712 commented Mar 3, 2025

@leaf-soba could you please fix the build error?

change the import order
@leaf-soba
Copy link
Contributor Author
leaf-soba commented Mar 5, 2025

@leaf-soba could you please fix the build error?

@chia7712, I have fixed the build error, but there is still one failing unit test: testDescribeQuorumRequestToControllers. I ran it locally, and it passed without any issues, so I'm not sure how to resolve this. Could you provide any hints?

@leaf-soba leaf-soba requested a review from chia7712 March 10, 2025 02:40
Copy link
Member
@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

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

@leaf-soba thanks for this patch. please take a look at a couple of minor comments.

@@ -920,10 +917,10 @@ public void testInitializeAsUnattachedAndBecomeLeader(boolean withKip853Rpc) thr
RecordBatch batch = records.batches().iterator().next();
assertTrue(batch.isControlBatch());

Record record = batch.iterator().next();
assertEquals(electionTimestamp, record.timestamp());
Record expectedRecord = batch.iterator().next();
Copy link
Member

Choose a reason for hiding this comment

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

Out of curiosity, what are the specific benefits associated with renaming it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@chia7712, I believe restricted identifiers should be avoided as variable names. While the code compiles, using such names can make it less readable and more confusing. For example:

var var = "var";

record Data(int id, String name) {} //record is used to define record classes

Renaming it to expectedRecord improves clarity and makes the intent of the variable more explicit.

@@ -969,10 +966,10 @@ public void testInitializeAsCandidateAndBecomeLeaderQuorumOfThree(boolean withKi
RecordBatch batch = records.batches().iterator().next();
assertTrue(batch.isControlBatch());

Record record = batch.iterator().next();
assertEquals(electionTimestamp, record.timestamp());
Record expectedRecord = batch.iterator().next();
Copy link
Member

Choose a reason for hiding this comment

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

ditto

@@ -3968,10 +3965,10 @@ public void testLeaderAppendSingleMemberQuorum(boolean withKip853Rpc) throws Exc
List<Record> readRecords = Utils.toList(leaderChangeBatch.iterator());
assertEquals(1, readRecords.size());

Record record = readRecords.get(0);
assertEquals(now, record.timestamp());
Record expectedRecord = readRecords.get(0);
Copy link
Member

Choose a reason for hiding this comment

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

ditto

assertNotNull(getMetric(context.metrics, "number-of-voters"));
assertNotNull(getMetric(context.metrics, "number-of-observers"));
assertNotNull(getMetric(context.metrics, "uncommitted-voter-change"));
List<String> metricNames = Arrays.asList(
Copy link
Member

Choose a reason for hiding this comment

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

        var metricNames = Set.of(
                "current-state", "current-leader", "current-vote", "current-epoch", "high-watermark",
                "log-end-offset", "log-end-epoch", "number-unknown-voter-connections", "poll-idle-ratio-avg",
                "commit-latency-avg", "commit-latency-max", "election-latency-avg", "election-latency-max",
                "fetch-records-rate", "append-records-rate", "number-of-voters", "number-of-observers",
                "uncommitted-voter-change"
        );

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@chia7712, Thanks for the suggestion! I've learned that using var and Set improves performance and ensures immutability.

use var instead of list
@leaf-soba leaf-soba requested a review from chia7712 March 17, 2025 09:21
@chia7712
Copy link
Member

@leaf-soba do you plan to file a follow-up to fix ClassFanOutComplexity?

@leaf-soba
Copy link
Contributor Author

@chia7712 yes I want to fix whole issue.

@chia7712 chia7712 merged commit 6f5be29 into apache:trunk Apr 17, 2025
20 checks passed
rreddy-22 pushed a commit to rreddy-22/kafka-rreddy that referenced this pull request Apr 21, 2025
…ntTest(1/2) (apache#18926)

- extract a unit test named `KafkaRaftClientClusterAuthTest` to reduce
the number of imported class

Reviewers: Chia-Ping Tsai <chia7712@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci-approved kraft tests Test fixes (including flaky tests)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0