test: add test coverage for ClientConnector

[Harsh16gupta]

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

Related Issue
Fixes #1934

This work was started after receiving maintainer approval in #1846.

Summary by CodeRabbit

• Tests
  • Added integration tests for the WebSocket Quarkus client to validate component rendering across multiple configuration scenarios.

[changeset-bot]

⚠️ No Changeset found

Latest commit: c04afb8

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]

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]

📝 Walkthrough

Walkthrough

Introduces a new test file for the WebSocket Quarkus client's ClientConnector component. The test suite covers three scenarios for pathName handling (explicitly null, undefined default, and fixture-derived), parsing an AsyncAPI document fixture and verifying rendered output with snapshot assertions.

Changes

Cohort / File(s)	Summary
ClientConnector Tests packages/templates/clients/websocket/java/quarkus/test/components/ClientConnector.test.js	New test file with beforeAll hook parsing AsyncAPI fixture data and three test cases validating ClientConnector component rendering under different pathName configurations using snapshot assertions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 6

✅ Passed checks (6 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows Conventional Commits guidelines with 'test:' prefix and uses imperative mood to clearly describe adding test coverage for ClientConnector.
Linked Issues check	✅ Passed	The PR successfully delivers component-level tests for ClientConnector.js covering the complex conditional logic as required by issue #1934.
Out of Scope Changes check	✅ Passed	The PR contains only the new test file ClientConnector.test.js, which is directly scoped to testing the ClientConnector component as specified in issue #1934.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into master
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ 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

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

🧹 Nitpick comments (2)

packages/templates/clients/websocket/java/quarkus/test/components/ClientConnector.test.js (2)

17-27: Add a guard assertion after parsing to catch fixture issues early.

If the fixture file is missing or contains invalid AsyncAPI, parseResult.document will be undefined, causing all tests to fail with cryptic errors (e.g., "Cannot read properties of undefined"). A simple assertion right after parsing makes failures obvious.

Proposed fix

   const parseResult = await fromFile(parser, asyncapiFilePath).parse();
   parsedAsyncAPIDocument = parseResult.document;
+  expect(parsedAsyncAPIDocument).toBeDefined();
   channels = parsedAsyncAPIDocument.channels();

---

29-62: Consider adding tests for query and operations variations.

The linked issue (#1934) calls for covering the component's "complex conditional logic." Currently, only pathName is varied across three tests. The component also branches on query (line 5 of ClientConnector.js: query && Array.from(query.entries())) and filters operations via operations.filterBySend(). Tests with query={null} and/or an AsyncAPI document with no send operations would exercise those paths.

Also, the null and undefined pathName tests exercise the exact same branch (!pathName → '/') and will produce identical snapshots — this is fine for explicitness, but adding the above variations would provide more meaningful coverage.

[derberg]

Thanks for the contribution. I’m closing this PR because, while there is an existing issue, it was not approved or opened for contribution before the pull request was submitted.

Please make sure to follow the contribution guidelines, which explain when issues are considered ready for implementation and when pull requests are appropriate

[Harsh16gupta]

Hi @derberg, thanks for the feedback.
@Adi-204 had given me permission to proceed with adding tests incrementally (see discussion in #1846). Based on that, I started submitting the tests one by one to keep the scope small and reviewable.

[derberg]

That was not specified in main issue and PR description. Reopening

[Harsh16gupta]

Thanks derberg for reopening the PR
Sorry for not mentioning the prior approval clearly.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Adi-204]

@Harsh16gupta for more smooth process please don't create PR directly let me drop a comment in issue so that easy for other maintainers to track. Thanks!

[Adi-204]

/rtm