With Vue Test Utils, how do you mount a component that calls `inject('theme')` and renders `$t('title')` without installing the real i18n plugin?

## What the component actually depends on A component that themes itself with `inject('theme')` and translates with `$t('title')` looks self-contained, but it quietly depends on two things that are normally set up once in `main.ts`: - an **injection** called `theme`, which some ancestor or the app itself must `provide`; - a **global instance property** called `$t`, which an i18n plugin normally adds to every component. In production both arrive because the app was built with `createApp(App)`, then `app.provide(...)` and `app.use(i18n)`. In a test, `mount()` from `@vue/test-utils` builds a brand-new app around the component and knows nothing about your `main.ts`. Unless you tell it otherwise, neither dependency exists. The key insight is that these are **two different lookup channels**, and each has its own mounting option. ## Channel one: `inject` reads the provides chain In Vue 3, `inject(key)` walks up the component's provides chain. For the root component of an app, that chain ends at the **app-level provides** that `app.provide(key, value)` writes. Vue Test Utils exposes that directly: - `global.provide` is a plain object; for every own key (string or `Symbol`), Vue Test Utils calls `app.provide(key, value)` on the app it creates for this mount; - the component's `inject('theme')` then finds `'dark'` exactly as if `main.ts` had provided it; - if your code uses an `InjectionKey` symbol, you must import that same symbol and use it as a computed key, `{ [ThemeKey]: 'dark' }`, because keys match by identity. ## Channel two: `$t` is an instance property The template expression `$t('title')` is not an injection. It is a property read on the component's render proxy. A real i18n plugin makes it resolve by adding a global property during `app.use(...)`. To fake it, Vue Test Utils offers `global.mocks`: - `global.mocks` is an object of instance properties, documented as meant for values injected by third-party plugins, such as `$t`, `$store` or `$route`; - Vue Test Utils applies it through a mixin whose `beforeCreate` puts each mock on the instance; - for `<script setup>` components it also wraps the render proxy so a template read of `$t` returns the mock. The docs warn that `global.mocks` is **not** for Vue's own properties such as `$root`. ## Putting both together ```ts import { mount } from '@vue/test-utils' import ThemedHeader from './ThemedHeader.vue' const wrapper = mount(ThemedHeader, { global: { provide: { theme: 'dark' }, mocks: { $t: (key: string) => `t:${key}` } } }) ``` A mock that returns its key with a visible prefix is a common choice: the test can assert that the right translation key was used without depending on real message files. ## What goes wrong without each option | Missing option | What Vue does | What the test sees | |---|---|---| | `global.provide` | dev warning `injection "theme" not found.` and `inject` returns `undefined` | the component renders with an undefined theme, so a class or style is wrong | | `global.mocks` for `$t` | dev warning that `$t` was accessed during render but is not defined on instance | the call on `undefined` throws and the render fails | | both present | nothing unusual | the component renders as in the app | Note that a missing injection does **not** throw. If `inject` was given a default, such as `inject('theme', 'light')`, there is not even a warning; the default silently wins, which can hide a test that forgot its provide. ## When a fake is the wrong tool Faking is the right call when the test is about **this component's** behaviour: which key it asks to translate, which class it applies for a theme. Two cases argue for the real thing instead: 1. The component calls a composable such as `useI18n()` rather than the `$t` global. Composables usually read an injection, which `global.mocks` never reaches; you then need `global.provide` with the library's key, or the real plugin in `global.plugins`. 2. The test is really about integration, such as a pluralisation rule or a locale switch. Then install the real plugin with a small message set through `global.plugins`. If every test in the suite needs the same `$t` fake, move it to `config.global.mocks` in a setup file rather than repeating it in each `mount`. ## Choosing what the fakes return A fake should make the assertion meaningful, not merely stop the warnings: - a `$t` that returns the key, or the key with a prefix, lets the test check **which** message the component asked for; - a `$t` that returns an empty string hides missing keys and makes text assertions useless; - a provided theme should be a value the component visibly reacts to, such as a class name, so the test proves the injection was read; - if the component should react to a theme change after mounting, provide a `ref` instead of a plain string and have the component read it reactively.