fusion-framework-mocking

Fusion Framework Mocking

When to use

Use when a test needs deterministic Fusion Framework module state — a signed-in user, a current context, seeded feature flags/bookmarks, or faked HTTP responses — without a real Entra ID tenant, service registry, or backend.

Typical triggers:

• "How do I mock useAccessToken / sign in a test user?"
• "Seed a current context for this test"
• "Fake this HTTP endpoint's response"
• "Mock service discovery so the app doesn't hit the network"
• "Add a mock for my own module"
• "Test signed-out / login / logout behavior"
• "Assert a middleware was called"

Implicit triggers:

• A test imports mockFramework, mockAppModules, or any @equinor/fusion-framework-module-*/mock entry point
• A test needs the app to boot without real credentials or a running backend
• Writing or reviewing a *.mock.ts/mock-configurator file for a Fusion module

When not to use

• Rendering a component/hook or configuring Vitest/Browser Mode — use fusion-framework-testing
• dev-server.config.ts API mocking/proxying for local ffc app dev — that is dev-time only, unrelated to test-time module mocks; see fusion-developer-app
• Asserting on one specific call (arguments, call count, reset) — that is the test runner's job (vi.spyOn, vi.fn); this skill only covers seeding module state
• Backend/service-repo test doubles (different repo, different stack)

Required inputs

Mandatory

• Which boundary needs faking: auth, service discovery, context, bookmarks, feature flags, HTTP, analytics, telemetry, app manifest, or a custom module
• Test scope: parent framework (mockFramework), an app's own modules (mockAppModules), or a bespoke module graph (a module's own enable*Mock)

Conditional

• Signed-in user details (name, username, specific token claims) when auth matters
• Whether the test must stay fully offline (every expected request needs an answering middleware)
• Whether an OpenAPI document already describes the API under test