@equinor/fusion-framework-vitest-plugin-react-app 1.0.0 → 1.0.2

package/docs/configuration.md

@@ -1,112 +0,0 @@
-# Configure Fusion React app tests
-
-The package exposes three entry points with different responsibilities:
-
-| Import | Responsibility |
-| --- | --- |
-| `@equinor/fusion-framework-vitest-plugin-react-app/config` | Build a browser-ready Vitest project with `defineProject` |
-| `@equinor/fusion-framework-vitest-plugin-react-app/test` | Resolve the app's files and provide `test` and `render` fixtures |
-| `@equinor/fusion-framework-vitest-plugin-react-app` | Configure the Vite plugin manually or render with explicit `env`, `configure`, and `fusion` options |
-
-## `defineProject` defaults
-
-```ts
-import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
-
-export default defineProject();
-```
-
-The default project registers `appTestVitePlugin()` and configures:
-
-- test files under `src/**/*.{test,spec}.{ts,tsx}`
-- Vitest Browser Mode enabled
-- the Playwright provider with one Chromium instance
-- headless browser execution
-- a `1024x768` default viewport, matching a typical low-resolution Citrix session rather than
-  Vitest's own mobile-sized default
-- Vite warmup for `src/**/*.{ts,tsx}` to discover lazy imports before tests run
-
-## Merge ordinary Vitest options
-
-Pass an object to deep-merge it with the defaults through Vite's `mergeConfig`:
-
-```ts
-import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
-import { name, version } from './package.json' with { type: 'json' };
-
-export default defineProject({
-  test: {
-    name: `${name}@${version}`,
-    // opt into a wider viewport for an app that only needs to support desktop
-    browser: { viewport: { width: 1920, height: 1080 } },
-  },
-});
-```
-
-These are standard Vitest and Vite options. Use the official Vitest configuration reference
-for runner behavior rather than looking for Fusion-specific equivalents.
-
-## Replace defaults deliberately
-
-Pass a function only when a deep merge cannot express the change. The function's return value
-replaces the defaults outright, so preserve every default the project still needs:
-
-```ts
-import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
-
-export default defineProject((defaults) => ({
-  ...defaults,
-  test: {
-    ...defaults.test,
-    include: ['tests/browser/**/*.test.tsx'],
-  },
-}));
-```
-
-When test files move outside `src`, update both `test.include` and `server.warmup.clientFiles`
-if those tests load lazy application modules.
-
-## Resolve non-standard app files
-
-Use `appTestVitePlugin` directly when the app manifest, app configuration, or module
-configurator does not use Fusion's normal file conventions:
-
-```ts
-import { playwright } from '@vitest/browser-playwright';
-import { appTestVitePlugin } from '@equinor/fusion-framework-vitest-plugin-react-app';
-import { defineProject } from 'vitest/config';
-
-export default defineProject({
-  plugins: [
-    appTestVitePlugin({
-      manifest: './config/app.manifest.ts',
-      config: './config/app.config.ts',
-      configure: './config/modules.ts',
-    }),
-  ],
-  test: {
-    browser: {
-      enabled: true,
-      provider: playwright(),
-      headless: true,
-      instances: [{ browser: 'chromium' }],
-    },
-  },
-  server: { warmup: { clientFiles: ['src/**/*.{ts,tsx}', '!src/**/*.d.ts'] } },
-});
-```
-
-`entrypoint`, `manifest`, and `config` use the same resolution pipeline as `ffc app build`
-and `ffc app dev`. `configure` must identify a real source file because the plugin re-exports
-its live application code into the test bundle. Explicit files that do not exist throw
-`FileNotFoundError`; convention-based lookups fall back to defaults.
-
-## Choose fixtures or explicit render options
-
-Use `/test` when the app's own files should resolve automatically. Use `renderAppHook`,
-`renderAppComponent`, or `testApp` from the root entry point when the test should pass `env`,
-`configure`, or a parent `fusion` instance explicitly.
-
-- [`test` and app rendering](getting-started.md)
-- [Detailed rendering and fixture APIs](../README.md#renderapphook)
-- [Troubleshooting configuration](troubleshooting.md)

package/docs/getting-started.md

@@ -1,66 +0,0 @@
-# Test a Fusion React app with Vitest
-
-Use `@equinor/fusion-framework-vitest-plugin-react-app` to render an existing Fusion React
-app in Vitest Browser Mode. The test runs in Chromium with a fresh framework and application
-module scope, a deterministic signed-in `Test User`, and no running portal or real credentials.
-
-## Install
-
-```sh
-pnpm add -D vitest playwright @vitest/browser-playwright vitest-browser-react \
-  @equinor/fusion-framework-vitest-plugin-react-app
-pnpm exec playwright install chromium
-```
-
-React, React DOM, RxJS, and Vite are peer dependencies that a Fusion React app normally
-already provides.
-
-## Configure Vitest
-
-Create `vitest.config.ts` at the app project root:
-
-```ts
-import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
-
-export default defineProject();
-```
-
-`defineProject` registers `appTestVitePlugin`, enables headless Chromium through Playwright,
-includes `src/**/*.{test,spec}.{ts,tsx}`, and warms application source files so lazy route
-imports do not reload the browser during a test.
-
-## Write the first app test
-
-```tsx
-import { expect } from 'vitest';
-import { test } from '@equinor/fusion-framework-vitest-plugin-react-app/test';
-import { App } from './App';
-
-test('renders the app', async ({ render }) => {
-  const screen = await render(<App />);
-  await expect.element(screen.getByRole('heading')).toBeVisible();
-});
-```
-
-The `/test` entry point resolves the app's manifest, `app.config.ts`, and module configurator
-through the registered Vite plugin. Always await `render`, `renderHook`,
-`renderAppComponent`, and `renderAppHook`; Fusion module initialization completes before the
-first render.
-
-## Run
-
-```sh
-pnpm exec vitest
-pnpm exec vitest run
-```
-
-The first command watches for changes. The second performs one run for CI. A successful run
-reports one passing test and requires no portal, credentials, or backend service.
-
-## Next steps
-
-- [Configure the test project and app-file resolution](configuration.md)
-- [Resolve common setup, browser, and network failures](troubleshooting.md)
-- [Seed Fusion module dependencies](module-mocks.md)
-- [Choose between app, framework, module, and HTTP test layers](../../../framework/docs/testing-choosing-a-layer.md)
-- [Seed authentication, context, service discovery, and HTTP](../README.md#overview)

package/docs/migrating-an-existing-app.md

@@ -1,202 +0,0 @@
-# Migrate an existing app to Fusion Vitest
-
-Use this guide to move existing application tests to
-`@equinor/fusion-framework-vitest-plugin-react-app`. It covers suites built with
-`@testing-library/react`, `jsdom` or `happy-dom`, hand-written Fusion hook mocks, and mock HTTP
-servers such as MirageJS, MSW, or Nock.
-
-You can migrate one test at a time. A mixed suite is a valid final state.
-
-## Choose which tests to migrate
-
-Start with tests that read from the application module scope through
-`useAppModule`, `useAccessToken`, `useCurrentContext`, `useCurrentBookmark`, `useFeature`, or a
-route that uses several Fusion modules. The plugin can replace their hand-written hook mocks
-with the real module pipeline and supported `enable*Mock` configuration.
-
-Keep pure functions, presentational components, and hooks with no Fusion dependency on their
-current runner when that is simpler. A test can also use the real Fusion module setup without
-Browser Mode by providing its own renderer. See
-[Why Browser Mode is the default](why-browser-mode.md#choose-a-different-runtime).
-
-## What changes, concretely
-
-| Existing pattern | Replace with |
-| --- | --- |
-| `@testing-library/react`'s `render`/`renderHook`/`waitFor`/`act`, on `jsdom` or `happy-dom` | `vitest-browser-react`'s `render`/`renderHook` and `vitest`'s `waitFor`/`act`, on real Chromium (Vitest Browser Mode) |
-| `vi.mock('@equinor/fusion-framework-react/hooks', ...)`, `vi.mock('.../feature-flag', ...)`, and similar hand-rolled Fusion hook mocks | The owning module's `enable*Mock` from its own `/mock` entry point. See [Module mocks](module-mocks.md) |
-| A hand-written mock HTTP server (MirageJS, `msw/node`, `nock`) answering every backend call | `configurator.http.addMiddleware(...)` with a hand-written `HttpMiddleware`, or `createRouterMiddleware` for several routes under one base URI. See [HTTP testing](../../../modules/http/docs/testing.md) |
-| A hand-rolled test wrapper composing a router, context providers, and error boundaries around every render | `test.extend(...)` fixtures stacked on the base `render`/`configureApp` fixtures. See [Compose a router and a domain fixture](#compose-a-router-and-a-domain-fixture) below |
-| Synchronous assertions (`expect(screen.getByText(...))`) | Browser locators and `await expect.element(screen.getByText(...)).toBeVisible()` |
-
-## Step 1: install Browser Mode dependencies
-
-```sh
-pnpm add -D vitest playwright @vitest/browser-playwright vitest-browser-react \
-  @equinor/fusion-framework-vitest-plugin-react-app
-pnpm exec playwright install chromium
-```
-
-Remove `@testing-library/react`, `@testing-library/dom`, `@testing-library/user-event`, and
-whichever `jsdom`/`happy-dom` package the app installed once every test that used them has
-migrated. Keep them if part of the suite intentionally stays on the old renderer.
-
-Replace the app's `vitest.config.ts` with the plugin's project config:
-
-```ts
-import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
-
-export default defineProject();
-```
-
-`defineProject` registers `appTestVitePlugin`, enables headless Chromium, includes
-`src/**/*.{test,spec}.{ts,tsx}`, and warms application source so lazy route imports don't reload
-the browser mid-test. See [Configuration](configuration.md) for overriding any of that.
-
-## Step 2: replace hand-rolled Fusion hook mocks
-
-The `/test` entry point initializes the real module pipeline. This removes most `vi.mock`
-implementations for hooks such as `useCurrentUser`, `useFeature`, and `useHttpClient`. The
-default setup includes a signed-in `Test User` and initialized feature-flag, context, and
-bookmark modules:
-
-```diff
--vi.mock('@equinor/fusion-framework-react/hooks', async (importOriginal) => ({
--  ...(await importOriginal()),
--  useCurrentUser: vi.fn(() => undefined),
--}));
--vi.mock('@equinor/fusion-framework-react-app/feature-flag', () => ({
--  useFeature: vi.fn(() => ({})),
--}));
-+import { enableFeatureFlagMock } from '@equinor/fusion-framework-module-feature-flag/mock';
-+import { test as baseTest } from '@equinor/fusion-framework-vitest-plugin-react-app/test';
-+
-+export const test = baseTest.extend('configureApp', ({ configureApp }) => (configurator, args) => {
-+  configureApp?.(configurator, args);
-+  configurator.msal.setAccount(null); // was: useCurrentUser returning undefined
-+  enableFeatureFlagMock(configurator, (mock) => mock.addFeature({ key: 'new-search', enabled: true }));
-+});
-```
-
-Each Fusion module owns its own mock entry point: `enableMsalMock`/`configurator.msal`,
-`enableFeatureFlagMock`, `enableContextMock`, `enableBookmarkMock`, and more. See
-[Module mocks](module-mocks.md) for the full list and each one's defaults. A hook or a small
-piece of app config with no Fusion dependency (for example, reading `environment` from the
-app's own manifest) stays a plain `vi.mock`.
-
-Some suites override `useModuleCurrentContext` directly and change its return value with
-`vi.spyOn`. Replace the initial value with `enableContextMock`. To change context after render,
-call the real module:
-`await fusion.app.context.setCurrentContextByIdAsync(otherProject.id)`. See the first
-[`renderAppComponent`](../README.md#renderappcomponent) example.
-
-## Step 3: port the mock HTTP server
-
-Use `createRouterMiddleware` for a mock server that handles several routes under one base URL:
-
-```diff
--import { createServer } from 'miragejs';
--
--export function createTestServer() {
--  return createServer({
--    routes() {
--      this.get('/activities/:id', (schema, request) => ({ id: request.params.id, ... }));
--      this.post('/activities', (schema, request) => ({ ... }));
--    },
--  });
--}
-+import { createRouterMiddleware } from '@equinor/fusion-framework-module-http/mock';
-+
-+export const activityRoutes = createRouterMiddleware('https://cpr-api.example.com', (router) => {
-+  router.get('/activities/:id', ({ params }) => Response.json({ id: params.id /* ... */ }));
-+  router.post('/activities', async ({ request }) => Response.json({ /* ... */ }));
-+});
-```
-
-Register the result with `configurator.http.addMiddleware(activityRoutes)` inside a `configureApp`
-fixture (see step 4). Port one route file at a time. Each ported file is independently testable.
-An unported route can fall through to the real network, so keep the old interceptor
-for tests that have not migrated yet or add a final fail-closed middleware; do not rely on a
-missing route to fail by itself. If the backend has an OpenAPI document, prefer
-`createOpenApiMockMiddleware` (`@equinor/fusion-framework-module-http/mock`) over hand-written
-routes; see [HTTP testing](../../../modules/http/docs/testing.md).
-
-If `useHttpClient` currently returns a plain `fetch` wrapper, remove that hook mock as well. The
-real client reaches middleware registered with `configurator.http.addMiddleware`. Register the
-router for the base URI used by the real client.
-
-## Compose a router and a domain fixture
-
-Use a `render` extension for JSX wrappers such as routers and app-owned React providers. Use a
-`configureApp` extension for Fusion module state. Stack both extensions when a test needs both:
-
-```tsx
-import type { ReactElement } from 'react';
-import { test as baseTest } from '@equinor/fusion-framework-vitest-plugin-react-app/test';
-import { Router } from '@equinor/fusion-framework-react-router';
-import type { RouteObject } from '@equinor/fusion-framework-react-router';
-import { enableContextMock } from '@equinor/fusion-framework-module-context/mock';
-
-// Every route matches, so the element under test stays mounted.
-const testWithRouter = baseTest.extend('render', () => (ui: ReactElement) => {
-  const routes: RouteObject[] = [{ path: '*', Component: () => ui }];
-  return baseTest.render(<Router routes={routes} />);
-});
-
-// The domain fixture uses the same shape as any other `configureApp` extension.
-export const test = testWithRouter.extend('configureApp', ({ configureApp }) => (configurator, args) => {
-  configureApp?.(configurator, args);
-  enableContextMock(configurator, (mock) => mock.setCurrentContext(projectA));
-});
-```
-
-A test importing this `test` gets both the router wrapper and seeded Fusion context.
-
-Keep app-owned React providers, such as authorization, schema, or snackbar providers, in the
-`render` extension. Move only Fusion module state to `configureApp` and `enable*Mock`.
-
-## Step 4: update renders and assertions
-
-Every render/hook helper is `async`, and most assertion helpers from `vitest-browser-react`
-resolve against the real browser rather than synchronously:
-
-```diff
--const { findByTestId } = render(<WrappedProcessPage {...props} />);
--await findByTestId('customization-panel');
-+const { getByTestId } = await render(<WrappedProcessPage {...props} />);
-+await expect.element(getByTestId('customization-panel')).toBeVisible();
-```
-
-`fireEvent`-style interactions become element method calls (`await screen.getByRole('button', {
-name: 'Activate' }).click()`), and `act`/`waitFor` come from `vitest` rather than
-`@testing-library/react`. See the [Vitest Browser Mode](https://vitest.dev/guide/browser/) and
-[mocking](https://vitest.dev/guide/mocking) guides for the general-purpose parts of this that
-aren't Fusion-specific.
-
-## Step 5: reassess DOM-emulation-only workarounds
-
-Review polyfills and component replacements that may only exist for `jsdom` or `happy-dom`.
-Remove one workaround at a time and run the affected tests against the real component.
-
-A common one: a no-op `window.ResizeObserver` stub carried over from `jsdom`/`happy-dom` setup.
-Real Chromium doesn't need the stub, but leaving it in place silently breaks any component that
-measures itself through `ResizeObserver` before rendering — for example a virtualized popover
-list. Remove the stub rather than porting it.
-
-Do not remove unrelated suppressions automatically. AG Grid license messages, Lit dev-mode
-warnings, network behavior, and app-specific test doubles may still apply in Browser Mode.
-
-## Migrate incrementally
-
-Nothing requires migrating a whole app in one pass. A common order: pick one page or route-level
-test that already hand-mocks several Fusion hooks, migrate it end to end (steps 1-4 above),
-confirm it's green, then migrate the next. Leave tests with no Fusion dependency on their
-current renderer for as long as that remains the cheaper option.
-
-## Related documentation
-
-- [Choose a Fusion testing layer](../../../framework/docs/testing-choosing-a-layer.md)
-- [Module mocks](module-mocks.md)
-- [HTTP testing](../../../modules/http/docs/testing.md)
-- [Advanced usage](advanced.md): composing fixtures and explicit render options
-- [Troubleshooting](troubleshooting.md)

package/docs/module-mocks.md

@@ -1,120 +0,0 @@
-# Mock Fusion dependencies in app tests
-
-Use module-owned `/mock` entry points to seed deterministic Fusion state while retaining each
-module's real configurator, provider, validation, and lifecycle. Import only the boundary the
-app test needs; the React app test fixture already composes the normal framework and app
-module scopes.
-
-| App dependency | Import path | Primary API |
-| --- | --- | --- |
-| Analytics | `@equinor/fusion-framework-module-analytics/mock` | `MockAnalyticsAdapter` |
-| App manifests and config | `@equinor/fusion-framework-module-app/mock` | `MockAppClient` |
-| Browser authentication | `@equinor/fusion-framework-module-msal/mock` | `enableMsalMock`, `MsalMockClient`, `createMockToken` |
-| Node authentication with Azure Identity | `@equinor/fusion-framework-module-azure-identity/mock` | `enableAuthMock`, `MockAuthProvider` |
-| Node authentication with MSAL | `@equinor/fusion-framework-module-msal-node/mock` | `enableAuthMock`, `MockAuthProvider` |
-| Bookmarks | `@equinor/fusion-framework-module-bookmark/mock` | `enableBookmarkMock`, `BookmarkMockConfigurator` |
-| Context | `@equinor/fusion-framework-module-context/mock` | `enableContextMock`, `ContextMockConfigurator` |
-| Context fixture generation | `@equinor/fusion-framework-module-context/mock/fixtures` | `createContextItemFactory`, `createContextItems` |
-| Feature flags | `@equinor/fusion-framework-module-feature-flag/mock` | `enableFeatureFlagMock`, `FeatureFlagMockConfigurator` |
-| HTTP routes and OpenAPI responses | `@equinor/fusion-framework-module-http/mock` | `createRouterMiddleware`, `createOpenApiMockMiddleware` |
-| Service discovery | `@equinor/fusion-framework-module-service-discovery/mock` | `enableServiceDiscoveryMock`, `ServiceDiscoveryMockConfigurator` |
-| Telemetry | `@equinor/fusion-framework-module-telemetry/mock` | `enableTelemetryMock`, `MockTelemetryAdapter` |
-
-The event module has no mock entry point. `waitForEvent` and `watchEvents` from
-`@equinor/fusion-framework-module-event/utils` observe the real event provider initialized by
-the app test fixture.
-
-## Authentication
-
-App tests start with a deterministic signed-in `Test User`. Set a named account or `null`
-through `configurator.msal.setAccount(...)` before rendering. The real MSAL provider still
-runs its initialization, account, token, and logout behavior against the in-process client.
-
-See [MSAL testing](../../../modules/msal/docs/testing.md) for signed-out startup, login flows,
-deterministic JWTs, and individual client spies.
-
-## App manifest and configuration
-
-The `/test` entry point automatically resolves the current app's manifest, `app.config.ts`,
-and module configurator. Use `enableAppManifestMock` when a custom parent framework must serve
-those values, or `mockAppModules` for app module testing without React.
-
-See [Application module testing](../../../app/docs/testing.md).
-
-## Context
-
-Use `enableContextMock` for known domain state without a context API or HTTP setup. The pool
-starts empty; `setCurrentContext` seeds and selects one item, while `setContexts` only makes
-items resolvable. Use HTTP middleware instead when the context service and transport pipeline
-are part of the test.
-
-See [Context testing](../../../modules/context/README.md#testing) for defaults, related-context
-behavior, and deterministic fixture generators.
-
-## Service discovery and HTTP
-
-Use `enableServiceDiscoveryMock` to resolve services from an in-memory registry. Use
-`configurator.http.addMiddleware` to answer a few explicit requests through the app's real
-named clients. Use `createOpenApiMockMiddleware` when an OpenAPI document describes many
-operations.
-
-- [Service discovery testing](../../../modules/service-discovery/docs/testing.md)
-- [HTTP testing](../../../modules/http/docs/testing.md)
-- [OpenAPI mock](../../../utils/openapi-mock/README.md)
-
-An HTTP middleware handles only requests for which it returns a `Response`. Calling
-`next(uri, init)` delegates to the next middleware and eventually the real network.
-
-## Events, analytics, and telemetry
-
-- Observe the real event provider with `waitForEvent` or `watchEvents` from
-  `@equinor/fusion-framework-module-event/utils`.
-- Register `MockAnalyticsAdapter` to record analytics without exporting them.
-- Use `enableTelemetryMock` and assert through `MockTelemetryAdapter.getItems` or
-  `waitForItem`.
-
-- [Event testing utilities](../../../modules/event/docs/testing.md)
-- [Analytics testing](../../../modules/analytics/docs/testing.md)
-- [Telemetry testing](../../../modules/telemetry/README.md#testing)
-
-## Seed several app dependencies
-
-Compose the app's real configuration with the module mocks required by the scenario:
-
-```tsx
-import { enableContextMock } from '@equinor/fusion-framework-module-context/mock';
-import { enableFeatureFlagMock } from '@equinor/fusion-framework-module-feature-flag/mock';
-import { test as baseTest } from '@equinor/fusion-framework-vitest-plugin-react-app/test';
-
-const project = {
-  id: 'project-a',
-  title: 'Project A',
-  type: { id: 'ProjectMaster' },
-  value: {},
-};
-
-export const test = baseTest.extend('configureApp', ({ configureApp }) => (configurator, args) => {
-  configureApp?.(configurator, args);
-  configurator.msal.setAccount({ name: 'Ada Lovelace' });
-  enableContextMock(configurator, (mock) => mock.setCurrentContext(project));
-  enableFeatureFlagMock(configurator, (mock) => {
-    mock.addFeature({ key: 'new-search', enabled: true });
-  });
-});
-```
-
-The fixture declarations are reusable, while every test still receives fresh framework and
-app module instances.
-
-## Choose direct module mocks or HTTP
-
-- Use a module mock for known domain state such as one current context, one account, or a set
-  of feature flags.
-- Use `configurator.http.addMiddleware` when the test must exercise the module's production
-  service-discovery, HTTP-client, and response-handling pipeline.
-- Use `createOpenApiMockMiddleware` when an OpenAPI document describes many operations.
-- Use Vitest `vi.fn`, `vi.spyOn`, or `vi.mock` for individual JavaScript calls rather than a
-  Fusion-specific wrapper.
-
-See each owning package README or `docs/testing.md` for its defaults, builder methods, and
-failure behavior.

package/docs/overview.md

@@ -1,49 +0,0 @@
-# Test Fusion React apps
-
-Fusion Framework uses Vitest for application tests. Vitest shares Vite's module and
-configuration model, runs components in a real browser, and owns the test runner, assertions,
-fixtures, spies, coverage, and editor integration. Fusion provides only the application scope
-and deterministic platform boundaries needed to test production behavior.
-
-Use `@equinor/fusion-framework-vitest-plugin-react-app` when a React hook, component, route,
-or complete app consumes Fusion modules. The package resolves app files, initializes the real
-framework and app provider nesting, and substitutes supported external clients without
-introducing a second testing language.
-
-## Choose the subject
-
-| Subject | Start with | What the test proves |
-| --- | --- | --- |
-| Pure function or framework-independent hook | Standard Vitest | Local behavior without a Fusion runtime |
-| Hook that consumes Fusion app modules | `renderAppHook` | Hook behavior inside an initialized app scope |
-| Component that consumes Fusion app modules | `/test` `render` fixture or `renderAppComponent` | Rendered behavior with real providers |
-| Route or complete application | `/test` `test` and `render` | App configuration, navigation, loaders, and module lifecycle together |
-| Framework or module integration without React | Package `/mock` entry points | Production provider behavior with external boundaries substituted |
-
-Prefer the smallest layer containing the behavior under assertion. A component test should
-not recreate a portal, while an app lifecycle test should not replace every Fusion hook with
-a JavaScript module mock.
-
-## Start here
-
-Follow [Getting started](getting-started.md) to install the browser dependencies, configure
-Vitest, and run one deterministic app test without credentials, a portal, or backend services.
-
-## Continue by task
-
-- [Configure Vitest defaults and non-standard app files](configuration.md)
-- [Compose fixtures and explicit render options](advanced.md)
-- [Seed Fusion module dependencies](module-mocks.md)
-- [Troubleshoot browser, app-resolution, and network failures](troubleshooting.md)
-- [Understand the Browser Mode default or choose another renderer](why-browser-mode.md)
-- [Migrate an existing app from Testing Library and DOM emulation](migrating-an-existing-app.md)
-- [Choose between app, framework, module, and HTTP testing](../../../framework/docs/testing-choosing-a-layer.md)
-
-Use the official Vitest documentation for generic runner concepts:
-
-- [Why Vitest](https://vitest.dev/guide/why)
-- [Writing tests](https://vitest.dev/guide/learn/writing-tests)
-- [Browser Mode](https://vitest.dev/guide/browser/)
-- [Test context and fixtures](https://vitest.dev/guide/test-context)
-- [Configuration](https://vitest.dev/config/)
-- [Mocking](https://vitest.dev/guide/mocking)

package/docs/troubleshooting.md

@@ -1,67 +0,0 @@
-# Troubleshoot Fusion React app tests
-
-Use this guide when a Fusion app test fails before the assertion, loads real services, cannot
-resolve the app, or behaves differently in Vitest Browser Mode.
-
-## Common symptoms
-
-| Symptom | Likely cause | Resolution |
-| --- | --- | --- |
-| Chromium executable is missing | Playwright installed without its browser binary | Run `pnpm exec playwright install chromium` |
-| The `/test` import cannot resolve Fusion virtual modules | `appTestVitePlugin` is not registered in this Vitest project | Export `defineProject()` from the package's `/config` entry point or register `appTestVitePlugin()` manually |
-| `FileNotFoundError` names a manifest, config, or configurator | An explicit plugin path does not exist | Correct the path relative to the Vitest project root; explicit paths fail instead of falling back |
-| The app's module configuration is not applied | No conventional `src/config.ts(x|js)` file was found | Pass `configure` to `appTestVitePlugin` or override the `configure` fixture |
-| A render result is a Promise or assertions run before initialization | A Fusion render helper was not awaited | Await `render`, `renderHook`, `renderAppComponent`, or `renderAppHook` |
-| A request reaches a live backend or fails with a network error | No HTTP middleware answered it | Add a matching `configurator.http.addMiddleware`; unmatched requests eventually reach the real network |
-| A lazy route import reloads the browser during a test | Source warmup no longer covers the lazy module | Keep `server.warmup.clientFiles` aligned with application source and route locations |
-| No tests are found | Tests are outside the default `src/**/*.{test,spec}.{ts,tsx}` pattern | Override `test.include` in `defineProject` |
-| The app starts signed in unexpectedly | The MSAL mock defaults to `Test User` | Set `configurator.msal.setAccount(null)` before rendering |
-| State configured in one test is missing in another | Framework and app fixtures are test-scoped | Seed the required state per test or publish reusable fixture declarations with `test.extend` |
-| `vi.spyOn` fails on an imported module in Browser Mode | Native ESM module namespace objects are sealed | Use `vi.mock('./module.js', { spy: true })` as documented by Vitest Browser Mode |
-| A `<Router>` route with a catch-all or parameterized `path` never renders; every query on it times out | The navigation module's current location does not match that path yet | Push the target location through the navigation module (`app.modules.navigation.push(path)`) before rendering, not after |
-| A virtualized list or popover (for example an EDS `Autocomplete` built on `@tanstack/react-virtual`) never renders its rows | `window.ResizeObserver` was stubbed as a no-op in test setup | Remove the stub; real Chromium's `ResizeObserver` is required for virtualized layout to measure correctly |
-| `test.each` runs but a fixture in its per-case callback is `undefined` | `test.each` does not forward `test.extend` fixture context to each case | Use Vitest's `test.for` instead, which does receive fixture context |
-
-## Verify the project wiring
-
-Start with the smallest configuration:
-
-```ts
-import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
-
-export default defineProject();
-```
-
-Then verify the fixture itself before testing application behavior:
-
-```tsx
-import { expect } from 'vitest';
-import { test } from '@equinor/fusion-framework-vitest-plugin-react-app/test';
-
-test('initializes a Fusion app scope', async ({ app, render }) => {
-  expect(app.auth.account?.name).toBe('Test User');
-  const screen = await render(<div>ready</div>);
-  await expect.element(screen.getByText('ready')).toBeVisible();
-});
-```
-
-If this test fails, fix project or app-file resolution before adding module-specific data.
-
-## Keep tests offline
-
-Fusion mocks replace known external boundaries, but an HTTP middleware is an ordered chain.
-Returning `next(uri, init)` delegates to the next middleware and eventually `fetch`. A test
-that must never use the network should register middleware for every expected request and
-fail deliberately on unexpected requests.
-
-Use `createOpenApiMockMiddleware` from
-`@equinor/fusion-framework-module-http/mock` when an OpenAPI document describes many routes.
-Use `vi.fn` around a middleware when the test also needs call assertions.
-
-## Related references
-
-- [Getting started](getting-started.md)
-- [Configuration and app-file resolution](configuration.md)
-- [Choose a Fusion testing layer](../../../framework/docs/testing-choosing-a-layer.md)
-- [HTTP middleware testing](../../../modules/http/docs/testing.md)
-- [Vitest Browser Mode limitations](https://vitest.dev/guide/browser/#limitations)