Convert hints editor unit tests to Vue Testing Library

[Swoyamjeetcodes]

Fixes #5815

Summary

Refactored channelEdit/components/HintsEditor/HintsEditor.spec.js to Vue Testing Library and rewrote the suite to reflect user interactions.

What changed

• Migrated from @vue/test-utils to:
  • @testing-library/vue (render, screen, within)
  • @testing-library/user-event
• Added a reusable renderComponent helper (with router + component stubs).
• Added a smoke test.
• Reworked test coverage to user-facing workflows:
  • empty state when no hints exist
  • rendering hint order
  • editing hint text
  • adding a new hint
  • opening another hint
  • moving hints up/down (including open index behavior)
  • deleting hints (including close/open behavior)
• Removed residual VTU usage/imports from the migrated file.

Manual verification

• Ran:
  • pnpm test contentcuration/contentcuration/frontend/channelEdit/components/HintsEditor/HintsEditor.spec.js
• Result:
  • Test Suites: 1 passed
  • Tests: 12 passed

UI evidence

• Screen recording (Hints workflow in Questions tab):

Screen recording (Hints workflow in Questions tab)

Before	After
View recording	View recording

Passed test cases

testcases.mp4

References

• Sub-issue of Migrate frontend tests from vue-test-utils to Vue Testing Library #5789

Reviewer guidance

• Review only this file:
  • contentcuration/contentcuration/frontend/channelEdit/components/HintsEditor/HintsEditor.spec.js
• Run:
  • pnpm test contentcuration/contentcuration/frontend/channelEdit/components/HintsEditor/HintsEditor.spec.js
• Please sanity-check:
  • User-focused test descriptions
  • Use of Testing Library query patterns
  • Open-index behavior around move/delete flows

AI usage

I used Codex (GPT-5) to help migrate the test suite and draft this PR description.
I critically reviewed and edited the generated output to match project testing conventions, removed unnecessary/legacy VTU patterns, and verified correctness by rerunning the migrated Jest file until all tests passed.

[learning-equality-bot]

👋 Hi @Swoyamjeetcodes, thanks for contributing!

For the review process to begin, please verify that the following is satisfied:

• Contribution is aligned with our contributing guidelines

• Pull request description has correctly filled AI usage section & follows our AI guidance:

  AI guidance

  
  

  State explicitly whether you didn't use or used AI & how.

  If you used it, ensure that the PR is aligned with Using AI as well as our DEEP framework. DEEP asks you:

  • Disclose — Be open about when you've used AI for support.
  • Engage critically — Question what is generated. Review code for correctness and unnecessary complexity.
  • Edit — Review and refine AI output. Remove unnecessary code and verify it still works after your edits.
  • Process sharing — Explain how you used the AI so others can learn.

  
  

  Examples of good disclosures:

  "I used Claude Code to implement the component, prompting it to follow the pattern in ComponentX. I reviewed the generated code, removed unnecessary error handling, and verified the tests pass."

  "I brainstormed the approach with Gemini, then had it write failing tests for the feature. After reviewing the tests, I used Claude Code to generate the implementation. I refactored the output to reduce verbosity and ran the full test suite."

Also check that issue requirements are satisfied & you ran pre-commit locally.

Pull requests that don't follow the guidelines will be closed.

Reviewer assignment can take up to 2 weeks.

[learning-equality-bot]

📢✨ Before we assign a reviewer, we'll turn on @rtibblesbot to pre-review. Its comments are generated by an LLM, and should be evaluated accordingly.

[rtibblesbot]

Clean migration — all acceptance criteria from #5815 met.

CI passing. Phase 3 skipped (no UI files changed). Two of the three PR videos (before/after recordings) failed to download — their S3 pre-signed URLs appear to have expired; only the test results video is accessible.

• praise: see inline — thorough open-index tracking coverage
• nitpick: see inline — toBeDefined() in clickToolbarAction

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Reviewed the pull request diff checking for:

• Correctness: bugs, edge cases, undocumented behavior, resource leaks, hardcoded values
• Design: unnecessary complexity, naming, readability, comment accuracy, redundant state
• Architecture: duplicated concerns, minimal interfaces, composition over inheritance
• Testing: behavior-based assertions, mocks only at hard boundaries, accurate coverage
• Completeness: missing dependencies, unupdated usages, i18n, accessibility, security
• Principles: DRY (same reason to change), SRP, Rule of Three (no premature abstraction)
• Checked CI status and linked issue acceptance criteria
• For UI changes: inspected screenshots for layout, visual completeness, and consistency

[rtibblesbot]

nitpick: toBeDefined() is a plain Jest matcher. Since buttons[hintIdx] is a DOM node, toBeInTheDocument() is more idiomatic Testing Library and produces a clearer failure message if the button isn't found at the expected index.

[learning-equality-bot]

📢✨ Before we assign a reviewer, we'll invite community pre-review. See the community review guidance for both authors and reviewers.