Skip to content

test: add test coverage for ClientFields#1984

Merged
asyncapi-bot merged 3 commits intoasyncapi:masterfrom
Harsh16gupta:test/ClientFields-1932
Feb 14, 2026
Merged

test: add test coverage for ClientFields#1984
asyncapi-bot merged 3 commits intoasyncapi:masterfrom
Harsh16gupta:test/ClientFields-1932

Conversation

@Harsh16gupta
Copy link
Contributor

@Harsh16gupta Harsh16gupta commented Feb 12, 2026

Description
Adds comprehensive integration tests for the ClientFields component in the Java Quarkus WebSocket client template.

Related Issue
Fixes #1932

image

Summary by CodeRabbit

  • Tests
    • Added comprehensive integration tests for the ClientFields component covering multiple queryParams scenarios to ensure robust functionality.

@changeset-bot
Copy link

changeset-bot bot commented Feb 12, 2026

⚠️ No Changeset found

Latest commit: 18c5ba3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@asyncapi-bot
Copy link
Contributor

What reviewer looks at during PR review

The following are ideal points maintainers look for during review. Reviewing these points yourself beforehand can help streamline the review process and reduce time to merge.

  1. PR Title: Use a concise title that follows our Conventional Commits guidelines and clearly summarizes the change using imperative mood (it means spoken or written as if giving a command or instruction, like "add new helper for listing operations")

    Note - In Generator, prepend feat: or fix: in PR title only when PATCH/MINOR release must be triggered.

  2. PR Description: Clearly explain the issue being solved, summarize the changes made, and mention the related issue.

    Note - In Generator, we use Maintainers Work board to track progress. Ensure the PR Description includes Resolves #<issue-number> or Fixes #<issue-number> this will automatically close the linked issue when the PR is merged and helps automate the maintainers workflow.

  3. Documentation: Update the relevant Generator documentation to accurately reflect the changes introduced in the PR, ensuring users and contributors have up-to-date guidance.

  4. Comments and JSDoc: Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions, so others can easily understand and use the code.

  5. DRY Code: Ensure the code follows the Don't Repeat Yourself principle. Look out for duplicate logic that can be reused.

  6. Test Coverage: Ensure the new code is well-tested with meaningful test cases that pass consistently and cover all relevant edge cases.

  7. Commit History: Contributors should avoid force-pushing as much as possible. It makes it harder to track incremental changes and review the latest updates.

  8. Template Design Principles Alignment: While reviewing template-related changes in the packages/ directory, ensure they align with the Assumptions and Principles. If any principle feels outdated or no longer applicable, start a discussion these principles are meant to evolve with the project.

  9. Reduce Scope When Needed: If an issue or PR feels too large or complex, consider splitting it and creating follow-up issues. Smaller, focused PRs are easier to review and merge.

  10. Bot Comments: As reviewers, check that contributors have appropriately addressed comments or suggestions made by automated bots. If there are bot comments the reviewer disagrees with, react to them or mark them as resolved, so the review history remains clear and accurate.

@coderabbitai
Copy link

coderabbitai bot commented Feb 12, 2026

📝 Walkthrough

Walkthrough

A new integration test file is added for the ClientFields component in the Java Quarkus WebSocket template. The test suite verifies component rendering with various queryParams scenarios using AsyncAPI fixture data and React testing utilities.

Changes

Cohort / File(s) Summary
ClientFields Component Test
packages/templates/clients/websocket/java/quarkus/test/components/ClientFields.test.js
Adds integration test for ClientFields component covering multiple queryParams scenarios (null, undefined, empty Map, populated from fixture) with snapshot assertions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title 'test: add test coverage for ClientFields' follows Conventional Commits guidelines with imperative mood and clearly describes the addition of test coverage for the ClientFields component.
Linked Issues check ✅ Passed The PR implements the objective from #1932 by adding comprehensive integration tests for ClientFields.js with various test scenarios and achieving 100% statement/line/function coverage as shown in the included coverage report.
Out of Scope Changes check ✅ Passed The PR only adds a single test file for ClientFields component with no changes to production code or unrelated areas, staying within the scope of issue #1932.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments
packages/templates/clients/websocket/java/quarkus/test/components/ClientFields.test.js (1)

15-20: Consider adding a guard assertion after parsing.

If the fixture file is invalid or missing, parseResult.document will be undefined, and all tests will fail with a cryptic Cannot read properties of undefined error on channels(). A simple assertion makes failures easier to diagnose.

Similarly, for the last test to be meaningful, it's worth asserting that queryParams is actually populated.

💡 Proposed improvement
   beforeAll(async () => {
     const parseResult = await fromFile(parser, asyncapiFilePath).parse();
     parsedAsyncAPIDocument = parseResult.document;
+    expect(parsedAsyncAPIDocument).toBeDefined();
     channels = parsedAsyncAPIDocument.channels();
     queryParams = getQueryParams(channels);
+    expect(queryParams.size).toBeGreaterThan(0);
   });

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@Adi-204 Adi-204 self-assigned this Feb 14, 2026
@Adi-204 Adi-204 moved this to In Progress in Maintainers work Feb 14, 2026
@sonarqubecloud
Copy link

@Adi-204
Copy link
Member

Adi-204 commented Feb 14, 2026

/rtm

@asyncapi-bot asyncapi-bot merged commit f6eeb4e into asyncapi:master Feb 14, 2026
14 of 15 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in Maintainers work Feb 14, 2026
@Harsh16gupta Harsh16gupta deleted the test/ClientFields-1932 branch February 14, 2026 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

[TEST] Add component tests for ClientFields.js (Java WebSocket Template)

3 participants