Agent skill · equinor
fusion-framework-mocking
Guides seeding deterministic Fusion Framework module state in tests — mockFramework, mockAppModules, and module-owned enableXMock helpers (msal, service-discovery, context, bookmark, feature-flag, analytics, telemetry, http, app) — while keeping each module''s real configurator, provider, validation, and lifecycle. USE FOR: signing in a mock user, seeding context/bookmarks/feature-flags, faking HTTP/OpenAPI responses, choosing a mock boundary, adding a mock for a custom module. DO NOT USE FOR: configuring vitest.config.ts, rendering React components/hooks, or Vitest Browser Mode setup (use fusion-framework-testing); dev-server-time API mocking/proxying in dev-server.config.ts (use fusion-developer-app); backend/service-repo mocking.
What it needs
About 4k tokens when loaded.
What this skill does
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 enableMock) 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 Instructions Step 1 — Understand the mocking design Read references/framework-and-app-mocks.md …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills equinor/fusion-framework-mocking