test: unify i18next mocks into centralized helpers - #42
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.
🤖 Augment PR SummarySummary: This PR standardizes how i18n is mocked in frontend tests by centralizing Changes:
Technical Notes: The new helper centralizes key-formatting behavior (namespace prefixing + param serialization) to keep test output consistent and reduce maintenance across the test suite. 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
|
|
||
| /** | ||
| * Create a t function with optional custom translations | ||
| * Checks translations[key] first, then translations[ns.key], then returns ns.key as fallback |
There was a problem hiding this comment.
The docstring says it checks translations[key] before translations[ns.key], but the implementation checks the namespaced key (fullKey) first. This mismatch can confuse test authors about which override will win when both forms are provided.
🤖 Was this useful? React with 👍 or 👎
| * Checks translations[key] first, then translations[ns.key], then returns ns.key as fallback | ||
| */ | ||
| export function createTFunction(translations: TranslationMap, defaultNs?: string) { | ||
| return (key: string, options?: Record<string, unknown>) => { |
There was a problem hiding this comment.
createTFunction no longer has the special-case for options.returnObjects that the previous global mock had, so calls like t('x', { returnObjects: true }) will now return a string with a JSON suffix instead of an array. If any component under test expects an array from i18next for list-like translations, this can change rendering/assertions in subtle ways.
🤖 Was this useful? React with 👍 or 👎
| */ | ||
| export function createUseTranslationMock(translations: TranslationMap = {}) { | ||
| return { | ||
| useTranslation: () => ({ |
There was a problem hiding this comment.
createUseTranslationMock's useTranslation mock ignores the namespace argument (useTranslation('someNs')) even though createTFunction accepts defaultNs. If any code relies on useTranslation(ns) to set the default namespace and then calls t() without { ns: ... }, the mock output will diverge from real behavior.
🤖 Was this useful? React with 👍 or 👎
| */ | ||
| export function createTransMock(translations: TranslationMap = {}) { | ||
| return { | ||
| Trans: ({ i18nKey, children }: { |
There was a problem hiding this comment.
createTransMock ignores common Trans props like components/values and always renders only children ?? i18nKey. Components that rely on <Trans ... components={{...}} /> (e.g., to render embedded links) may not render the expected nodes in tests, reducing assertion fidelity.
🤖 Was this useful? React with 👍 or 👎
|
|
||
| - `useTranslation` - returns translation keys with namespace prefix | ||
| - `Trans` component - renders i18nKey and components | ||
| - `useMixedTranslation` (from `@/app/components/plugins/marketplace/hooks`) |
There was a problem hiding this comment.
This section attributes useMixedTranslation/useGetLanguage (and Trans component rendering) to the global mock in web/vitest.setup.ts, but that setup only mocks react-i18next and the current Trans mock doesn’t render components. Consider rewording to avoid implying these hooks/components are provided by the global mock when they come from their own modules / aren’t fully simulated.
Other Locations
.claude/skills/frontend-testing/references/mocking.md:56.claude/skills/frontend-testing/assets/component-test.template.tsx:31
🤖 Was this useful? React with 👍 or 👎
3 participants
Benchmark PR from qodo-benchmark#437