chore(claude): auto-register new integration tests in test suites

[dsilvam]

Summary

• Adds Step 6c to the gh-issue-troubleshoot slash command
• After writing any new test file under dotcms-integration/src/test/java/, the skill now automatically detects the JUnit version and registers the class in the correct suite file
• JUnit 5 → Junit5Suite1.java (@SelectClasses)
• JUnit 4 → least-loaded of MainSuite1a/1b/2a/2b/3a (@SuiteClasses), keeping CI load balanced
• Adds both the import (alphabetically) and the ClassName.class, entry; warns and skips if the package can't be determined

Test plan

• Run /gh-issue-troubleshoot on an issue that requires a new integration test and verify the suite file is updated automatically
• Verify JUnit 4 test lands in the suite with the fewest entries
• Verify JUnit 5 test lands in Junit5Suite1.java
• Verify no suite edit happens when no new test file is created

🤖 Generated with Claude Code

[github-actions]

❌ Issue Linking Required

This PR could not be linked to an issue. All PRs must be linked to an issue for tracking purposes.

How to fix this:

Option 1: Add keyword to PR body (Recommended - auto-removes this comment)
Edit this PR description and add one of these lines:

• This PR fixes #123 or Fixes: #123

• This PR closes #123 or Closes: #123

• This PR resolves #123 or Resolves: #123

• Other supported keywords: fix, fixed, close, closed, resolve, resolved
  Option 2: Link via GitHub UI (Note: won't clear the failed check)

1. Go to the PR → Development section (right sidebar)

2. Click "Link issue" and select an existing issue

3. Push a new commit or re-run the workflow to clear the failed check
   Option 3: Use branch naming
   Create a new branch with one of these patterns:

• 123-feature-description (number at start)

• issue-123-feature-description (issue-number at start)

• feature-issue-123 (issue-number anywhere)

Why is this required?

Issue linking ensures proper tracking, documentation, and helps maintain project history. It connects your code changes to the problem they solve.---

This comment was automatically generated by the issue linking workflow

[claude]

Claude finished @dsilvam's task in 1m 59s —— View job

---

Review

• Read the changed file
• Verified the suite files referenced actually exist
• Checked the JUnit-detection and least-loaded logic for edge cases

Findings

This is a docs/skill-prompt change to .claude/commands/gh-issue-troubleshoot.md — no runtime code affected. A few real issues worth fixing before this is relied on to mutate suite files automatically:

1. Trailing-comma bug in the append instruction (will produce non-compiling Java).
Step 6c-3 tells the skill to insert NewTestClass.class, before the closing }). That works for MainSuite3a (last entry already has a trailing comma) but breaks Junit5Suite1.java, whose last entry has no trailing comma:

ContentImportResourceIntegrationTest.class,
JobProcessorDiscoveryTest.class      ← no comma
})

Naively appending NewTestClass.class, yields a compile error (missing comma after JobProcessorDiscoveryTest.class). The instruction should explicitly cover both shapes: "If the previous last entry has no trailing comma, add one before inserting."

2. No idempotency / duplicate check.
Nothing tells the skill to verify the class isn't already in some suite (or in the one being edited). Re-running /gh-issue-troubleshoot on the same issue would silently duplicate entries. Worth a short "skip if ClassName.class is already present in any of the suite files" guard.

3. "Alphabetical import insertion" doesn't match reality.
Existing imports in these suites are not alphabetized (e.g., in MainSuite3a.java com.dotmarketing.fixtask.tasks.FixTask00090... sits between two com.dotmarketing.startup.runonce.Task... imports). Telling the skill to insert "in alphabetical order with the other imports" gives it conflicting signals. Simpler and safer: "append the new import at the end of the existing import block."

4. JUnit version heuristic is brittle for non-obvious cases.

• org.junit.platform.* covers suite-only platform APIs; a real JUnit 5 test almost always imports org.junit.jupiter.api.*. That's fine.
• A test that only imports org.junit.Assert (no Test, no runner.*) — possible for abstract bases or helpers — matches neither rule. Document the fallback ("if neither rule matches, warn and skip", same as the missing-package branch).
• The skill is also not told to filter out non-test files placed under src/test/java (abstract base classes, fixtures, *IT infra). Anything Write-n there will be treated as a registerable test. Add a check that the class actually contains @Test (jupiter or junit) before touching a suite.

5. "Least-loaded" counting method is unspecified.
MainSuite2b is 551 lines vs. 88–125 for the others, so balancing matters. But "count @SuiteClasses entries" is fuzzy — entries can be one-per-line or wrapped, and some are fully-qualified inline (e.g., MainSuite3a.java:68-74). Spell it out: "count occurrences of .class, (and the final .class without comma) inside the @SuiteClasses({ ... }) block."

6. Excluded suites aren't justified.
OpenSearchUpgradeSuite.java and QuickSuite.java exist alongside the MainSuite* files but are intentionally left out of the load-balancing pool. One-line justification in the doc would prevent future maintainers (or the skill itself) from "helpfully" adding them.

7. Ordering nit: numbering churn.
Renumbering 6c→6d→6e is fine for now, but if step 6 keeps growing this re-lettering will be a recurring source of stale references. Consider numbered sub-steps (6.1, 6.2, …) so future inserts don't shift labels.

8. Minor: trailing blank line added at line 245 (between "If y, run the command…" and ---). Cosmetic only.

Nothing here is unsafe at runtime — worst case the skill produces a broken edit a human reviews before commit — but #1 will reliably break the JUnit 5 suite on the first real use, and #2 is a foot-gun on re-runs.
· Branch: chore/gh-issue-troubleshoot-test-suite-registration