test: migrate RearrangeChannelsPage, AvailableChannelsPage, NewChannelVersionPage from VTU to VTL (Part 2-4/4) (#14261)

[soaebhasan12]

Summary

Migrate remaining device plugin tests to Vue Testing Library as part of issue #14261.
This is Part 2-4 of 4 — consolidated into a single PR per reviewer guidance on PR #14883:

• ChannelTokenModal.spec.js (merged in test: migrate ChannelTokenModal.spec.js from VTU to VTL (#14261) #14883)
• RearrangeChannelsPage.spec.js (in progress — this PR)
• AvailableChannelsPage.spec.js
• NewChannelVersionPage.spec.js

Each file has its own commit(s) for easier review.

Status

This is a draft/work-in-progress PR opened early to get feedback on an open question
(see comment below) before continuing with the remaining files.

Open question

I'm stuck on mocking DragContainer for RearrangeChannelsPage — see comment below for details.

AI usage

I used Claude AI as a learning tool and coding assistant during this VTL migration,
consistent with the approach disclosed in PR #14883.

[learning-equality-bot]

👋 Hi @soaebhasan12, 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.

[soaebhasan12]

hello @AlexVelezLl @rtibblesbot
I'm migrating RearrangeChannelsPage.spec.js to VTL. Since DragContainer uses
@shopify/draggable (which doesn't work in jsdom), I mocked it with a simple stub
component that just renders its slot plus a button I can click to trigger the
sort event manually.

jest.mock('kolibri-common/components/sortable/DragContainer', () => ({
  default: {
    name: 'DragContainer',
    props: ['items'],
    template: `<div><button data-testid="trigger-sort" @click="...">...</button><slot /></div>`,
  },
}));

The problem: when there are channels to show, nothing renders inside that mocked
component — not even the channel names — and there's no error or warning in the
console either. It just silently shows nothing. The empty-state case (no channels)
works fine though.

I'm guessing it might have something to do with Draggable/DragHandle (the children
inside DragContainer's slot) expecting something from the real DragContainer that
my mock doesn't provide, but I'm not sure.

Any suggestions on how to approach mocking this component correctly?

[AlexVelezLl]

Hey @soaebhasan12! Could you check why the current mock works, and what the difference is? Could you also rebase against the latest develop now that we have made some changes to the DragContainer implementation? Perhaps that could help!

[soaebhasan12]

Hey @soaebhasan12! Could you check why the current mock works, and what the difference is? Could you also rebase against the latest develop now that we have made some changes to the DragContainer implementation? Perhaps that could help!

Thanks @AlexVelezLl! Rebased against develop and figured it out.

You were right — the develop branch now uses sortablejs instead of @shopify/draggable, and I found the pattern in DragContainer.spec.js (mocking sortablejs itself rather than the DragContainer component). Switched to that approach:

jest.mock(
  'sortablejs',
  () => jest.fn().mockImplementation((el, options) => ({ destroy: jest.fn(), options })),
  { virtual: true },
);

This lets the real DragContainer (and its Draggable/DragHandle children) render normally, and I can grab the captured onEnd callback from Sortable.mock.results to simulate a completed drag. All tests pass now. Thanks for pointing me in the right direction!

[soaebhasan12]

Update: RearrangeChannelsPage.spec.js is complete — all 7 tests passing
(loads data, instructions text, empty state, successful/failed @sort, moveUp, moveDown),
pre-commit clean.

Moving on to AvailableChannelsPage.spec.js next, which I understand is the more
complex one (router, store, filters). Will push that as a separate commit once ready.