@equinor/fusion-framework 8.0.14 → 8.1.0-next.0

package/dist/types/__tests__/mock/application-module.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/types/__tests__/mock/documented-usage.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/types/__tests__/mock/mock-framework.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/types/mock/FrameworkMockConfigurator.d.ts

@@ -0,0 +1,185 @@
+import type { AnyModule } from '@equinor/fusion-framework-module';
+import { type ContextMockConfigurator } from '@equinor/fusion-framework-module-context/mock';
+import { type IHttpClientConfigurator } from '@equinor/fusion-framework-module-http';
+import { type MsalMockConfigurator } from '@equinor/fusion-framework-module-msal/mock';
+import { type ServiceDiscoveryMockConfigurator } from '@equinor/fusion-framework-module-service-discovery/mock';
+import { type IApiConfigurator } from '@equinor/fusion-framework-module-services';
+import { type TelemetryMockConfigurator } from '@equinor/fusion-framework-module-telemetry/mock';
+import { FrameworkConfigurator } from '../FrameworkConfigurator.js';
+/**
+ * The real framework configurator, with every built-in module that reaches
+ * outside the process backed by a test double, and every other built-in
+ * module reachable the same way.
+ *
+ * @remarks
+ * Nothing else changes: the same module set, the same configuration pipeline and
+ * the same lifecycle are used. Only the boundaries that would need credentials or
+ * network access are substituted, so a test still exercises module wiring,
+ * configuration validation and lifecycle hooks.
+ *
+ * Every built-in module exposes its own configurator as a property, so a test
+ * reaches it directly instead of registering a callback to receive it. `http`
+ * is the real configurator — fake a response by registering a
+ * short-circuiting middleware through `.http.addMiddleware(...)` instead of
+ * swapping the module out; see `@equinor/fusion-framework-module-http/mock`'s
+ * `createOpenApiMockMiddleware` for faking a whole `@equinor/fusion-openapi-mock`
+ * document that way. `services` is not backed by a test double yet either, so
+ * calls through its configurator still reach the network — but
+ * the configurator itself is reachable the same way `.msal` is, since its
+ * `configure` factory takes no `ref` and so loses nothing by being pinned early.
+ *
+ * `event` is deliberately not pinned: its `configure` factory reads `ref` to
+ * wire bubbling to a parent event provider when this configurator is hoisted
+ * inside a host framework, and pinning would freeze that decision before a
+ * `ref` could ever be known.
+ *
+ * Because this *is* a `FrameworkConfigurator`, every `enableX` helper an
+ * application already uses accepts it unchanged — including the ones an
+ * application team writes for their own modules.
+ *
+ * @typeParam TModules - Module descriptors beyond the built-in set. Supply this
+ *   when a test registers application modules, so they are typed on the resulting
+ *   instance.
+ *
+ * @example
+ * ```typescript
+ * const configurator = new FrameworkMockConfigurator();
+ *
+ * configurator.msal.setAccount({ name: 'Ada Lovelace' });
+ * configurator.serviceDiscovery.setBaseUri('http://localhost:6669');
+ *
+ * const fusion = await init(configurator);
+ * ```
+ */
+export declare class FrameworkMockConfigurator<TModules extends Array<AnyModule> = []> extends FrameworkConfigurator<TModules> {
+    #private;
+    static readonly className: string;
+    /**
+     * Creates a framework configurator backed by the built-in mock modules.
+     */
+    constructor();
+    /**
+     * Pins a module to a single configurator instance for the lifetime of this
+     * configurator, so it can be reached by name through {@link _getConfig}.
+     *
+     * @remarks
+     * The module system otherwise builds a fresh configurator from its own
+     * `configure` factory during the configure phase — too late for a test to
+     * reach, and a new instance on every call besides. This replaces that
+     * factory with one that always returns the same instance, and registers the
+     * result under the module's own name.
+     *
+     * A subclass registering a module supplied through {@link TModules} uses
+     * this the same way `.msal` and `.serviceDiscovery` do, to expose its own
+     * named accessor:
+     *
+     * ```typescript
+     * class MyMockConfigurator extends FrameworkMockConfigurator<[InvoiceModule]> {
+     *   constructor() {
+     *     super();
+     *     this._pin(invoiceMockModule);
+     *   }
+     *
+     *   public get invoices(): InvoiceMockConfigurator {
+     *     return this._getConfig('invoices');
+     *   }
+     * }
+     * ```
+     *
+     * @param module - The module descriptor to pin a configurator for.
+     * @template TModule - The specific module descriptor type being pinned.
+     * @throws {Error} If the module declares no `configure` factory to pin, or
+     *   the factory returns a promise instead of a configurator — pinning is
+     *   synchronous, so a test can reach the accessor immediately.
+     */
+    protected _pin<TModule extends AnyModule>(module: TModule): void;
+    /**
+     * Returns the configurator pinned for a module by name.
+     *
+     * @param name - The module's name, as passed to {@link _pin}.
+     * @template TConfig - The specific configurator type expected for this module.
+     * @returns The configurator pinned under `name`.
+     * @throws {Error} If no configurator has been pinned for that name.
+     */
+    protected _getConfig<TConfig>(name: string): TConfig;
+    /**
+     * Configures the user the framework signs in.
+     *
+     * @remarks
+     * The same {@link MsalMockConfigurator} the auth module is configured from, so
+     * a change made here is what the module sees.
+     *
+     * @returns The MSAL mock configurator.
+     */
+    get msal(): MsalMockConfigurator;
+    /**
+     * Configures the registry services are resolved from.
+     *
+     * @remarks
+     * The same {@link ServiceDiscoveryMockConfigurator} the service discovery
+     * module is configured from, so a change made here is what the module sees.
+     *
+     * @returns The service discovery mock configurator.
+     */
+    get serviceDiscovery(): ServiceDiscoveryMockConfigurator;
+    /**
+     * Configures the HTTP module's named clients.
+     *
+     * @remarks
+     * The same {@link IHttpClientConfigurator} the HTTP module is configured
+     * from — the real one, not a test double. Register a short-circuiting
+     * {@link HttpMiddleware} through `addMiddleware` to answer from that
+     * instead of the network.
+     *
+     * @returns The real HTTP configurator.
+     */
+    get http(): IHttpClientConfigurator;
+    /**
+     * Configures the typed API clients the `services` module builds.
+     *
+     * @remarks
+     * The real configurator — `services` has no test double yet.
+     *
+     * @returns The real API configurator.
+     */
+    get services(): IApiConfigurator;
+    /**
+     * Configures context resolution.
+     *
+     * @remarks
+     * The same {@link ContextMockConfigurator} the context module is configured
+     * from, so seeding an item here is what `fusion.modules.context` resolves.
+     *
+     * @returns The context mock configurator.
+     */
+    get context(): ContextMockConfigurator;
+    /**
+     * Configures telemetry.
+     *
+     * @remarks
+     * The same {@link TelemetryMockConfigurator} the telemetry module is
+     * configured from, so a tracked event or measurement can be read back from
+     * its adapter instead of reaching Application Insights.
+     *
+     * @returns The telemetry mock configurator.
+     */
+    get telemetry(): TelemetryMockConfigurator;
+    /**
+     * Registers a module through its own enabler.
+     *
+     * @remarks
+     * Sugar for calling the enabler directly — `enableMyModuleMock(configurator)`
+     * works just as well, because this class *is* a `FrameworkConfigurator`. Use
+     * whichever reads better at the call site.
+     *
+     * @param configure - Callback receiving this configurator.
+     * @returns This configurator, for chaining.
+     *
+     * @example
+     * ```typescript
+     * configurator.addModule((c) => enableMyModuleMock(c, { total: 42 }));
+     * ```
+     */
+    addModule(configure: (configurator: this) => void): this;
+}
+export default FrameworkMockConfigurator;

package/dist/types/mock/index.d.ts

@@ -0,0 +1,29 @@
+/**
+ * Zero-configuration Fusion Framework instances for tests.
+ *
+ * @remarks
+ * Lets an application initialize the real framework — real modules, real
+ * configuration pipeline, real lifecycle — while the boundaries that reach
+ * outside the process are substituted with deterministic fakes. No credentials,
+ * no network access and no configuration are required.
+ *
+ * This entry point holds **no mock logic**. Each module owns and exports its own
+ * test double from its `./mock` entry point; this entry point only composes the
+ * built-in set into a ready-to-use instance. An application module follows the
+ * same pattern and plugs in identically.
+ *
+ * This entry point is test-runner agnostic: it contains no dependency on Vitest
+ * or any other test framework, so the same helpers work under any runner.
+ *
+ * Fixture generators with realistic fake data (e.g. `createContextItems`) live
+ * on each module's own `/mock/fixtures` entry point instead of here, since they
+ * pull in an extra dependency ({@link https://fakerjs.dev/ | faker}) that
+ * plain configurator mocking doesn't need.
+ *
+ * @packageDocumentation
+ */
+export { mockFramework, type FrameworkMockConfigureFn } from './mock-framework.js';
+export { FrameworkMockConfigurator } from './FrameworkMockConfigurator.js';
+export { enableMsalMock, msalMockModule, MsalMockConfigurator, MsalMockClient, createMsalMockClient, createMockToken, type AuthConfigMockFn, type MsalMockUser, type MockTokenClaims, } from '@equinor/fusion-framework-module-msal/mock';
+export { mockServiceDiscovery, enableServiceDiscoveryMock, serviceDiscoveryMockModule, ServiceDiscoveryMockClient, ServiceDiscoveryMockConfigurator, createMockService, defaultServiceDiscoveryMockServices, type ServiceDiscoveryConfigMockFn, type MockService, type ServiceDiscoveryMockClientOptions, } from '@equinor/fusion-framework-module-service-discovery/mock';
+export { enableContextMock, contextMockModule, ContextMockConfigurator, type ContextMockConfigFn, type ContextResolverFn, } from '@equinor/fusion-framework-module-context/mock';

package/dist/types/mock/mock-framework.d.ts

@@ -0,0 +1,58 @@
+import type { AnyModule } from '@equinor/fusion-framework-module';
+import type { Fusion } from '../types.js';
+import { FrameworkMockConfigurator } from './FrameworkMockConfigurator.js';
+/**
+ * Configures a mocked framework before it is initialized.
+ *
+ * @typeParam TModules - Module descriptors beyond the built-in set.
+ * @param configurator - The configurator to configure.
+ */
+export type FrameworkMockConfigureFn<TModules extends Array<AnyModule> = []> = (configurator: FrameworkMockConfigurator<TModules>) => void | Promise<void>;
+/**
+ * Starts a Fusion framework instance that needs no credentials and no network.
+ *
+ * @remarks
+ * The real framework is started: the real module set, the real configuration
+ * pipeline and the real lifecycle. Only the boundaries that would need
+ * credentials or network access are substituted, so a test exercises the wiring
+ * an application actually depends on rather than a reimplementation of it.
+ *
+ * The configurator passed to `configure` is a {@link FrameworkMockConfigurator},
+ * which *is* a `FrameworkConfigurator`. Every `enableX` helper therefore accepts
+ * it unchanged — including the ones an application team writes for their own
+ * modules.
+ *
+ * Spying on individual calls is left to the test runner. The framework makes the
+ * runtime substitutable; `vi.spyOn`, `bun:test` `spyOn` and `t.mock.method` all
+ * work against the resulting instance with no framework support.
+ *
+ * @typeParam TModules - Module descriptors beyond the built-in set. Supply this
+ *   when a test registers application modules, so they are typed on the result.
+ * @template TModules - Module descriptors beyond the built-in set.
+ * @param configure - Callback that configures the framework before it starts.
+ * @returns The initialized framework instance.
+ *
+ * @example Zero configuration
+ * ```typescript
+ * const fusion = await mockFramework();
+ * ```
+ *
+ * @example Configure the built-in mocks
+ * ```typescript
+ * const fusion = await mockFramework((configurator) => {
+ *   configurator.msal.setAccount({ name: 'Ada Lovelace' });
+ *   configurator.serviceDiscovery.setBaseUri('http://localhost:6669');
+ * });
+ * ```
+ *
+ * @example Register an application module
+ * ```typescript
+ * const fusion = await mockFramework<[InvoiceModule]>((configurator) => {
+ *   enableInvoicesMock(configurator, { total: 42 });
+ * });
+ *
+ * await fusion.modules.invoices.getInvoice('1');
+ * ```
+ */
+export declare function mockFramework<TModules extends Array<AnyModule> = []>(configure?: FrameworkMockConfigureFn<TModules>): Promise<Fusion<TModules>>;
+export default mockFramework;

package/dist/types/version.d.ts

@@ -1 +1 @@
-export declare const version = "8.0.14";
+export declare const version = "8.1.0-next.0";

package/docs/testing-api.md

@@ -0,0 +1,25 @@
+# API
+
+| Export | Owner | Purpose |
+| --- | --- | --- |
+| `mockFramework<TModules>(configure?)` | `/mock` | Build and initialize a framework instance for a test |
+| `FrameworkMockConfigurator<TModules>` | `/mock` | `FrameworkConfigurator` whose outward boundaries are mocked, exposing `msal`, `serviceDiscovery`, `http` and `context` |
+| `enableMsalMock(configurator, configure?)` | `-module-msal/mock` | Register the auth module with an in-process MSAL client |
+| `msalMockModule` | `-module-msal/mock` | The auth module with a mock client, for manual registration |
+| `MsalMockConfigurator` | `-module-msal/mock` | `MsalConfigurator` backed by a mock client (`setAccount`, `setClient`, …) |
+| `MsalMockClient(config)` | `-module-msal/mock` | Build the in-process MSAL client on its own, from the same `MsalClientConfig` as `MsalClient` |
+| `createMsalMockClient(config, user?)` | `-module-msal/mock` | Convenience alias for `new MsalMockClient(config)`, optionally signing a user in |
+| `createMockToken(claims?)` | `-module-msal/mock` | Mint a deterministic JWT |
+| `mockServiceDiscovery(configurator, options?, configure?)` | `-module-service-discovery/mock` | Replace service discovery with an in-memory registry |
+| `enableServiceDiscoveryMock(configurator, configure?)` | `-module-service-discovery/mock` | Register the discovery module with an in-memory registry |
+| `ServiceDiscoveryMockConfigurator` | `-module-service-discovery/mock` | `ServiceDiscoveryConfigurator` that builds an in-memory registry (`setBaseUri`, `addService`, …) |
+| `ServiceDiscoveryMockClient(options?)` | `-module-service-discovery/mock` | Build the in-memory discovery client on its own |
+| `defaultServiceDiscoveryMockServices` | `-module-service-discovery/mock` | Baseline services a Fusion app resolves at start-up |
+| `createMockService(service, baseUri?)` | `-module-service-discovery/mock` | Expand a sparse service declaration into a full `Service` |
+| `configureHttp(configure)` | `-module-http` | Build a module config that pairs `configureClient`/`configureHttpClient` and `addMiddleware` for `configurator.addConfig(...)` — the real module, no mock client |
+| `createOpenApiMockMiddleware(mock)` | `-module-http/mock` | Adapt an `@equinor/fusion-openapi-mock` instance into an `HttpMiddleware`, for use with `configurator.http.addMiddleware(...)` |
+| `enableContextMock(configurator, configure?)` | `-module-context/mock` | Register the context module with an in-memory seeded pool |
+| `contextMockModule` | `-module-context/mock` | The context module with a mock client, for manual registration |
+| `ContextMockConfigurator` | `-module-context/mock` | `ContextModuleConfigurator` backed by in-memory context items (`setCurrentContext`, `setContexts`, `addContext`, `setRelatedContexts`, `setResolver`) |
+
+Module-owned exports are re-exported from `@equinor/fusion-framework/mock` for convenience; importing them from their own package is equally valid.

package/docs/testing-choosing-a-layer.md

@@ -0,0 +1,90 @@
+# Choose a Fusion testing layer
+
+Start with the smallest layer that initializes the production behavior the test needs. Fusion
+test utilities substitute external boundaries; Vitest still owns tests, assertions, lifecycle
+hooks, spies, timers, coverage, and general module mocking.
+
+## Which import should I use?
+
+| Testing intent | Start with | Import |
+| --- | --- | --- |
+| Pure function or framework-independent hook | Standard Vitest | `vitest` |
+| React hook that consumes app modules | `renderAppHook` | `@equinor/fusion-framework-vitest-plugin-react-app` |
+| React component, route, or complete Fusion app | Extended `test` and `render` fixture | `@equinor/fusion-framework-vitest-plugin-react-app/test` |
+| Reusable app fixture without automatic app-file resolution | `testApp` | `@equinor/fusion-framework-vitest-plugin-react-app` |
+| Application module configuration without React | `mockAppModules` | `@equinor/fusion-framework-app/mock` |
+| Parent framework or portal-level modules | `mockFramework` | `@equinor/fusion-framework/mock` |
+| One module in a bespoke module graph | That module's `enable*Mock` helper | `@equinor/fusion-framework-module-*/mock` |
+| Named HTTP clients and a few deterministic responses | `configurator.http.addMiddleware` | Real HTTP configurator |
+| Many HTTP operations described by OpenAPI | `createOpenApiMockMiddleware` | `@equinor/fusion-framework-module-http/mock` |
+| One method call, timer, global, or JavaScript module | Vitest's `vi` APIs | `vitest` |
+
+## React app tests
+
+Use `@equinor/fusion-framework-vitest-plugin-react-app/test` for the normal application path.
+Its `test` and `render` exports resolve the app's manifest, `app.config.ts`, and module
+configurator, then initialize a fresh framework and app scope for each 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();
+});
+```
+
+Use the root entry point's `renderAppHook`, `renderAppComponent`, or `testApp` only when the
+test should provide `env`, `configure`, or a parent `fusion` instance explicitly. See the
+[`@equinor/fusion-framework-vitest-plugin-react-app` documentation](../../vitest-plugin/react-app/README.md).
+
+## Framework and module tests
+
+Use `mockFramework` when code consumes the parent framework directly or when the test needs
+to seed several built-in framework modules together:
+
+```ts
+import { mockFramework } from '@equinor/fusion-framework/mock';
+
+const fusion = await mockFramework((configurator) => {
+  configurator.msal.setAccount({ name: 'Ada Lovelace' });
+  configurator.context.setCurrentContext({
+    id: 'project-a',
+    title: 'Project A',
+    type: { id: 'ProjectMaster' },
+    value: {},
+  });
+  configurator.serviceDiscovery.addService({ key: 'catalog' });
+});
+```
+
+Use a module-owned `/mock` entry point when assembling a custom module graph or testing the
+module without the standard framework set. Module mocks keep the real provider,
+configurator, validation, and lifecycle; only the client or data source that leaves the
+process is substituted.
+
+## Choosing how to fake data
+
+| Need | Preferred boundary | Why |
+| --- | --- | --- |
+| One known context item | `enableContextMock` | Seeds domain data without transport setup |
+| Context service integration | HTTP middleware | Exercises service discovery, HTTP, and context client behavior together |
+| One or two HTTP routes | Hand-written `HttpMiddleware` | Keeps the response behavior explicit |
+| An API described by OpenAPI | `createOpenApiMockMiddleware` | Generates deterministic responses for the whole specification |
+| An individual client call | `vi.spyOn` | Uses the test runner's call assertions and reset semantics |
+
+An HTTP middleware handles only matching requests. Calling `next(uri, init)` continues to the
+next middleware and eventually the real network. Tests intended to be fully offline should
+fail or answer every request they expect.
+
+## Related package documentation
+
+- [Framework mock usage](testing.md)
+- [Framework mock design](testing-design.md)
+- [Framework mock exports](testing-api.md)
+- [Add a mock for a custom module](testing-extending.md)
+- [Application module testing](../../app/docs/testing.md)
+- [HTTP testing](../../modules/http/docs/testing.md)
+- [Migrate an existing app to Fusion Vitest](../../vitest-plugin/react-app/docs/migrating-an-existing-app.md)

package/docs/testing-design.md

@@ -0,0 +1,63 @@
+# Design
+
+Why this entry point exists, what it substitutes, and the rules that keep it from growing into a mocking library.
+
+## Why this exists
+
+Fusion Framework cannot start without authenticating a user and resolving services from a registry. Both reach outside the process, so an application test either has to supply real credentials or hand-build a replacement for every built-in module.
+
+This entry point removes that work. It runs the **real** configure → initialize pipeline with the **real** built-in modules, and substitutes only the boundaries that leave the process.
+
+That distinction matters: module wiring, configuration validation and lifecycle hooks behave exactly as they do in production, so a test still catches wiring mistakes.
+
+## How mocks are organised
+
+> [!IMPORTANT]
+> This entry point contains **no mock logic**. Every module owns and exports its own test double from a `./mock` entry point. This entry point only composes the built-in set.
+
+```
+@equinor/fusion-framework-module-msal/mock               -> enableMsalMock
+@equinor/fusion-framework-module-service-discovery/mock  -> mockServiceDiscovery
+@equinor/fusion-framework/mock                           -> composes the above
+```
+
+Three consequences follow, and they are the reason for the split:
+
+- **Mocks cannot drift.** A test double lives beside the implementation it stands in for, so a change to the real interface breaks it in the same package, in the same build.
+- **Mocks version with their module.** Installing msal `v10` gets msal `v10`'s mock. There is no version matrix to reconcile.
+- **Application modules work the same way.** A team's own module exposes its own mock entry point and composes without this entry point knowing it exists.
+
+Adding mock support to another Fusion module means adding a `src/mock/` folder to that module — not editing this entry point.
+
+## What is actually substituted
+
+> [!IMPORTANT]
+> Only the **client** — the object that performs network I/O — is replaced. Providers, configurators, schema validation and module `initialize` are all real.
+
+For authentication this means `MsalProvider` itself runs. A test therefore observes real provider behaviour, including decisions the provider makes on the caller's behalf:
+
+```typescript
+const fusion = await mockFramework((configurator) => {
+  configurator.msal.setClientConfig({ auth: { clientId: 'my-app', tenantId: 'my-tenant' } });
+});
+
+const token = await fusion.modules.auth.acquireAccessToken();
+// scope is 'my-app/.default' — resolved by the real provider, not by the test double
+```
+
+A double that replaced the provider would have skipped that logic and quietly reported whatever it was told to.
+
+## Determinism
+
+Tokens and resolved services are identical across runs and across machines. `createMockToken` uses a fixed issue time, so a token can be compared or snapshotted directly.
+
+## Test-runner support
+
+The package has **no test-runner dependency**. It builds a real framework instance and returns it; assertions are the caller's concern. It works under Vitest today and would work unchanged under another runner.
+
+`vitest` appears only in `devDependencies`, for this entry point's own tests.
+
+> [!IMPORTANT]
+> This is deliberate, and it is why there is **no Fusion mocking API**. The framework's job is making the runtime *substitutable* — a real configurator that validates, an I/O-boundary client that needs no network or credentials, a registry you compose on the builder. Replacing an individual call is your runner's job, and it does it better: call assertions, argument matchers and reset semantics you already know.
+>
+> Mock clients are therefore plain classes with ordinary methods. `vi.spyOn`, `bun:test`'s `spyOn` and Node's `t.mock.method` all work on them directly.

package/docs/testing-extending.md

@@ -0,0 +1,102 @@
+# Adding a mock for another module
+
+How to give a module a test double, whether it is one of ours or one of yours.
+
+## Mocking your own module
+
+An application module needs no support from this entry point. Ship a test double next to the module and apply it alongside the framework mocks.
+
+Two seams matter, and the second is the one teams miss:
+
+1. **A client seam** — `setClient`, the way `MsalConfigurator.setClient` and `setServiceDiscoveryClient` do — so the object performing I/O can be swapped.
+2. **Configuration on the builder** — so a test can adjust behaviour *without* constructing a client at all. `ServiceDiscoveryMockConfigurator.addService` is the reference: the configurator accumulates config, and the client is built from it when the module assembles its config.
+
+```typescript
+// @my-app/module-invoices/mock
+export const mockInvoices = (configurator, options = {}) => {
+  configurator.addConfig(
+    configureInvoices((builder) => {
+      builder.setClient({
+        getInvoice: async (id) => ({ id, total: options.total ?? 100 }),
+      });
+    }),
+  );
+};
+```
+
+```typescript
+// @my-app/module-invoices — the module's own type, exported for tests
+export type InvoiceModule = Module<'invoices', InvoiceClient, InvoiceConfigurator>;
+```
+
+Pass that descriptor to `mockFramework` as a type argument, and the module is typed on both the configurator and the returned instance:
+
+```typescript
+const fusion = await mockFramework<[InvoiceModule]>((configurator) => {
+  enableInvoicesMock(configurator, { total: 42 });
+});
+
+await fusion.modules.invoices.getInvoice('inv-1'); // typed, no cast
+```
+
+### Giving your module the same accessor as `.msal` and `.serviceDiscovery`
+
+`enableInvoicesMock(configurator, options)` is enough on its own — the configurator it builds is discarded once configuration runs, which is fine when a test only ever sets options up front. Reach for an accessor when a test needs the configurator itself, for example to assert against it after the fact.
+
+Subclass `FrameworkMockConfigurator` and use the protected `_pin`/`_getConfig` pair it exposes for exactly this — the same mechanism `.msal` and `.serviceDiscovery` are built from:
+
+```typescript
+class AppMockConfigurator extends FrameworkMockConfigurator<[InvoiceModule]> {
+  constructor() {
+    super();
+    this._pin(invoiceMockModule);
+  }
+
+  get invoices(): InvoiceMockConfigurator {
+    return this._getConfig('invoices');
+  }
+}
+```
+
+`_pin` replaces the module's own `configure` factory with one that always returns the same instance — pinning it before initialization runs is what lets a test reach `.invoices` synchronously and have it be the configurator the module is actually built from. `_getConfig` looks that instance up by name, throwing if nothing was pinned for it.
+
+## What is not covered yet
+
+`.services` and `.telemetry` are already reachable on `FrameworkMockConfigurator` — their `configure` factories take no `ref`, so they were safe to pin the same way `.msal` and `.serviceDiscovery` are. What is missing is a test double behind them: neither module has a `src/mock/` folder yet, so anything issuing an actual request through them still reaches the network. Adding one means creating that folder in **that module**, then pinning its mock configurator with `_pin` and exposing it with `_getConfig` on `FrameworkMockConfigurator`, replacing the real module descriptor pinned there today.
+
+`event` is not pinned at all, deliberately: its `configure` factory reads `ref` to wire event bubbling to a parent event provider when `FrameworkMockConfigurator` is hoisted inside a host framework. Pinning would call `configure()` with `ref` always `undefined`, silently breaking that bubbling — so it is left to build the normal way, from the module system's own configure phase, where `ref` is actually known.
+
+## `.http`
+
+`.http` is the real `HttpClientConfigurator` built from `@equinor/fusion-framework-module-http` — there is no separate mock client. Register a short-circuiting middleware through `addMiddleware` to answer requests without touching the network:
+
+```typescript
+configurator.http.configureClient('catalog', { baseUri: 'https://api.example.com' });
+configurator.http.addMiddleware(async (uri, init, next) =>
+  uri === 'https://api.example.com/items' ? Response.json([{ id: 1 }]) : next(uri, init),
+);
+
+const items = await fusion.modules.http.createClient('catalog').json('/items');
+```
+
+A middleware is `(uri, init, next) => Response | Promise<Response> | Observable<Response>` — return a `Response` to answer the request, or call and return `next(uri, init)` to fall through to whichever middleware (or the real network call) is registered next. Two ways to fill that seam:
+
+- **`addMiddleware`** — a hand-rolled middleware for a handful of routes, as above.
+- **`createOpenApiMockMiddleware`** (`@equinor/fusion-framework-module-http/mock`) — adapts an `@equinor/fusion-openapi-mock` instance (`createOpenApiMock(document)`), so a real `openapi.json`/`openapi.yaml` fakes every response with no handlers written at all until an edge case needs overriding.
+
+## `.context`
+
+`.context` is backed by `ContextMockConfigurator` (`@equinor/fusion-framework-module-context/mock`): context items live in an in-memory pool instead of a real context API, so a test needs no HTTP mock and no service-discovery mock to seed a known item.
+
+```typescript
+configurator.context.setCurrentContext({ id: 'my-ctx', type: { id: 'ProjectMaster' }, value: {} });
+
+fusion.modules.context.currentContext; // the seeded item, resolved on startup
+```
+
+Real `ContextProvider` behaviour — `validateContext`, `resolveContext`, parent-context propagation — still runs against the seeded data; only the data source is substituted. Two layers cover different needs:
+
+- **`setCurrentContext`/`setContexts`/`addContext`/`setRelatedContexts`** — a friendly, context-domain vocabulary for the common case: seed a known item, get it back.
+- **`setResolver`** — an escape hatch for a custom `resolveContext` strategy or a shape the friendly layer did not anticipate.
+
+Seeding a context item this way is one of two ways to fake context in a test — the other is mocking the context API's HTTP responses directly (with `.http`, optionally paired with `createOpenApiMockMiddleware`), which exercises the real `ContextModuleConfigurator`/services/HTTP pipeline instead of substituting it. Reach for `.context` to seed one known item with no transport involved; reach for `.http` when the test needs to cover that pipeline itself.