Migrate Device transfer modal tests to Vue Testing Library

[soaebhasan12]

Summary

Migrated two test files from @vue/test-utils to Vue Testing Library
as described in issue #14263:

• SelectDriveModal.spec.js — 9 tests migrated
• SelectTransferSourceModal.spec.js — 2 tests migrated

Changes made:

• Replaced mount with render from @testing-library/vue
• Replaced internal element queries with user-facing queries
  (getByText, queryByText, getAllByRole, getByRole, getByTestId)
• Removed all @vue/test-utils imports
• Rewrote makeWrapper as renderComponent following the pattern
  in CoreMenuOption.spec.js

Verified all tests pass:

pnpm run test-jest -- --testPathPattern device
Test Suites: 19 passed, 19 total
Tests: 461 passed, 461 total

References

Closes #14263

Reviewer guidance

Run the following command to verify all tests pass:

pnpm run test-jest -- --testPathPattern device

The main files changed are:

• kolibri/plugins/device/frontend/views/__tests__/SelectDriveModal.spec.js
• kolibri/plugins/device/frontend/views/__tests__/SelectTransferSourceModal.spec.js

No other files were modified.

AI usage

I used Claude (AI assistant) to support this contribution.

Disclose: I used Claude to understand Vue Testing Library concepts
and the difference between @vue/test-utils and VTL patterns.

Engage critically: I did not use AI output directly. For each test,
I analyzed what the original test was asserting, then chose the
appropriate VTL query based on Testing Library's query priority
guidelines. For example:

• Used getAllByRole('radio') instead of CSS selectors to count drives
• Used getByRole('button', { name: 'Continue' }) instead of
  find('button[name="submit"]')
• Used getByText for visible text assertions instead of
  component-internal checks

Edit: I removed makeWrapper, getElements, and unnecessary stubs.
I also discovered that passing the Vuex store directly via store:
option worked correctly, while global: { plugins: [store] } did not
— I debugged this by reading error messages and testing different
approaches.

Process sharing: I referenced CoreMenuOption.spec.js as the
pattern guide mentioned in the issue, and used Claude to clarify
concepts when stuck. All final decisions on test structure and
assertions were made by me after reading the Testing Library docs.

I reviewed every test carefully to make sure it reflects real user
interactions — for example, using getByText to find visible text
instead of CSS classes, and getByRole('button') instead of
find('button[name="submit"]').

I ran the full test suite to verify nothing was broken.

[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]

👋 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]

closed by mistake...

[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 — both files are free of @vue/test-utils, tests use semantic VTL queries, and the pattern matches CoreMenuOption.spec.js. CI is mostly pending but no failures.

• suggestion: count-only radio assertion in SelectDriveModal (see inline)
• suggestion: two removed tests leave a coverage gap for the primary selection interaction
• praise: getByRole('button', { name: 'Continue' }) + toBeDisabled() is good; stubs in SelectTransferSourceModal are well-reasoned

---

@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

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.20.0.dev0_git.20260409094305.pex
Windows Installer (EXE)	kolibri-0.20.0.dev0+git.20260409094305-windows-setup-unsigned.exe
Debian Package	kolibri_0.20.0.dev0+git.20260409094305-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.20.0.dev0+git.20260409094305.dmg
Android Package (APK)	kolibri-0.20.0.dev0+git.20260409094305-0.1.7-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.20.0.dev0+git.20260409094305.zip
TAR file	kolibri-0.20.0.dev0+git.20260409094305.tar.gz
WHL file	kolibri-0.20.0.dev0+git.20260409094305-py2.py3-none-any.whl

Smoke test screenshot

Download screenshot

[rtibblesbot]

No new code changes since the prior review — only a develop merge commit that doesn't touch the test files. Re-raising two unaddressed suggestions below.

CI passing.

Prior findings

Unaddressed (re-raised below):

• Radio count doesn't verify which drives are shown (suggestion) — no reply, no code change
• Two coverage gaps: "Continue" enabled on selection, "Cancel" event (suggestion) — no reply, no code change

0/2 prior suggestions resolved. 2 re-raised below.

---

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

How was this generated?

Compared the current PR state against findings from a prior review:

• Retrieved prior bot reviews deterministically via the GitHub API
• Classified each prior finding as RESOLVED, UNADDRESSED, ACKNOWLEDGED, or CONTESTED
• Only raised NEW findings for newly introduced code
• Reviewed the pull request diff checking for correctness, design, architecture, testing, completeness, and adherence to DRY/SRP principles
• Checked CI status and linked issue acceptance criteria
• For UI changes: inspected screenshots for layout, visual completeness, and consistency

[rtibblesbot]

Prior suggestions addressed; one nitpick on the new commit.

CI passing. Phase 3 skipped — no UI files changed.

Prior findings

N prior findings unchanged (2 from initial review, still resolved).

Newly resolved:

• Radio count doesn't verify which drives are shown (suggestion) ← was UNADDRESSED — getByText assertion added at SelectDriveModal.spec.js:77
• Missing test for drive-selected enables Continue (suggestion) ← was UNADDRESSED — test added at SelectDriveModal.spec.js:131

2/2 prior findings resolved. 0 re-raised below.

---

Findings:

• 1 nitpick (inline)
• 1 praise (inline)

---

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

How was this generated?

Compared the current PR state against findings from a prior review:

• Retrieved prior bot reviews deterministically via the GitHub API
• Classified each prior finding as RESOLVED, UNADDRESSED, ACKNOWLEDGED, or CONTESTED
• Only raised NEW findings for newly introduced code
• Reviewed the pull request diff checking for correctness, design, architecture, testing, completeness, and adherence to DRY/SRP principles
• Checked CI status and linked issue acceptance criteria