test: unify i18next mocks into centralized helpers#132
Conversation
Consolidate scattered i18next mock implementations across test files into a single source of truth. This reduces duplication and ensures consistent mock behavior. - Create test/i18n-mock.ts with reusable factory functions - Update vitest.setup.ts to use the centralized helpers - Remove redundant mock definitions from 8 test files - Update testing.md documentation 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…eateReactI18nextMock` and detail global mock provisions.
Code Review by Qodo
1. TranslationMap uses interface
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| import * as React from 'react' | ||
| import { vi } from 'vitest' | ||
|
|
||
| interface TranslationMap extends Record<string, string | string[]> {} |
There was a problem hiding this comment.
1. translationmap uses interface 📘 Rule violation ✓ Correctness
• web/test/i18n-mock.ts introduces interface TranslationMap, which conflicts with the project requirement to use type aliases instead of interface declarations. • Keeping type declarations consistent avoids style drift and prevents ESLint ts/consistent-type-definitions violations across the frontend codebase.
Agent prompt
## Issue description
`web/test/i18n-mock.ts` uses an `interface` for `TranslationMap`, but the project standard requires `type` aliases.
## Issue Context
The repo enforces `ts/consistent-type-definitions`-style consistency: prefer `type Name = ...` over `interface Name { ... }`.
## Fix Focus Areas
- web/test/i18n-mock.ts[4-4]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+2759
to
+2767
| // Note: The global mock returns the key with namespace prefix (plugin.) | ||
| expect(screen.getByText('plugin.category.all')).toBeInTheDocument() | ||
| expect(screen.getByText('plugin.category.models')).toBeInTheDocument() | ||
| expect(screen.getByText('plugin.category.tools')).toBeInTheDocument() | ||
| expect(screen.getByText('plugin.category.datasources')).toBeInTheDocument() | ||
| expect(screen.getByText('plugin.category.triggers')).toBeInTheDocument() | ||
| expect(screen.getByText('plugin.category.agents')).toBeInTheDocument() | ||
| expect(screen.getByText('plugin.category.extensions')).toBeInTheDocument() | ||
| expect(screen.getByText('plugin.category.bundles')).toBeInTheDocument() |
There was a problem hiding this comment.
2. Marketplace spec exceeds max-lines 📘 Rule violation ⛯ Reliability
• web/app/components/plugins/marketplace/index.spec.tsx is well above the configured SonarJS max-lines limit (1000), as evidenced by code existing past line 2700. • This increases maintenance cost and makes test navigation/refactoring harder; the PR also modifies this file, so it’s a good opportunity to split it into smaller spec files.
Agent prompt
## Issue description
`web/app/components/plugins/marketplace/index.spec.tsx` exceeds the configured SonarJS `max-lines` threshold (1000), hurting maintainability.
## Issue Context
The file currently contains multiple large describe blocks (components + hooks) and has grown beyond the configured line limit.
## Fix Focus Areas
- web/app/components/plugins/marketplace/index.spec.tsx[2759-2767]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+332
to
+338
| The global mock provides: | ||
|
|
||
| - `useTranslation` - returns translation keys with namespace prefix | ||
| - `Trans` component - renders i18nKey and components | ||
| - `useMixedTranslation` (from `@/app/components/plugins/marketplace/hooks`) | ||
| - `useGetLanguage` (from `@/context/i18n`) - returns `'en-US'` | ||
|
|
There was a problem hiding this comment.
3. I18n docs vs setup 🐞 Bug ⛯ Reliability
• Docs/templates state that the global Vitest i18n mock also provides useMixedTranslation and useGetLanguage, and that useGetLanguage returns 'en-US'. • In reality, web/vitest.setup.ts only globally mocks react-i18next; useMixedTranslation/useGetLanguage come from other modules and are not globally mocked. • This mismatch is likely to cause brittle tests (wrong expectations like 'en-US' vs actual 'en_US') and confusion about when per-test mocks are required.
Agent prompt
### Issue description
Documentation/templates state that the global Vitest setup provides mocks for `useMixedTranslation` and `useGetLanguage`, and that `useGetLanguage` returns `'en-US'`. However, `web/vitest.setup.ts` only mocks `react-i18next`. Also, docs claim `Trans` “renders i18nKey and components”, but the mock `Trans` implementation ignores `components`.
### Issue Context
This mismatch can cause future tests to be written with incorrect assumptions (wrong locale string expectations, or missing mocks for `@/context/i18n` / marketplace hooks).
### Fix Focus Areas
- web/testing/testing.md[330-338]
- .claude/skills/frontend-testing/references/mocking.md[52-66]
- .claude/skills/frontend-testing/assets/component-test.template.tsx[29-39]
- web/vitest.setup.ts[88-96]
- web/test/i18n-mock.ts[54-63]
### Suggested approach
Choose one:
1) **Docs-only fix (lowest risk):** Update docs/templates to say the global mock only covers `react-i18next` and remove/adjust claims about `useMixedTranslation`/`useGetLanguage` and the `'en-US'` return value. Clarify that `useGetLanguage` returns the normalized locale (e.g. `en_US`). Clarify `Trans` mock behavior (doesn’t interpolate `components` unless overridden).
2) **Behavior fix:** If you truly want these globally mocked, add explicit `vi.mock` entries in `web/vitest.setup.ts` for `@/app/components/plugins/marketplace/hooks` and `@/context/i18n` and update `createTransMock` to accept/render `components`/`ns` in a predictable test-friendly way.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Benchmark PR from qodo-benchmark#437