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.
- Installs
- 94
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/equinor/fusion-skills --skill fusion-framework-mocking- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads fusion-framework-mocking automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
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-*/mockentry 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.tsAPI mocking/proxying for localffc app dev— that is dev-time only, unrelated to test-time module mocks; seefusion-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 ownenable*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
Instructions
Step 1 — Understand the mocking design
Read references/framework-and-app-mocks.md for the design rules before writing a mock:
- Only the client (the object doing network I/O) is substituted. Providers, configurators,
schema validation, and module
initializeall run for real — a test still catches wiring mistakes. - Mocks live beside the module they replace, at that module's own
/mockentry point.@equinor/fusion-framework/mockonly composes the built-in set; it contains no mock logic of its own. - There is no Fusion mocking API for individual calls. Mock clients are plain classes with
ordinary methods — use
vi.spyOn,bun:test'sspyOn, or Node'st.mock.methoddirectly.
Step 2 — Pick the right layer
| Test scope | Use | Import |
|---|---|---|
| Parent framework / portal-level modules together | mockFramework | @equinor/fusion-framework/mock |
| An app's own modules (no React) | mockAppModules | @equinor/fusion-framework-app/mock |
| One module in a bespoke module graph | that module's enable*Mock | @equinor/fusion-framework-module-*/mock |
| React hooks/components consuming app modules | render helpers (out of scope here) | see fusion-framework-testing |
import { mockFramework } from '@equinor/fusion-framework/mock';
const fusion = await mockFramework((configurator) => {
configurator.msal.setAccount({ name: 'Ada Lovelace' });
configurator.context.setCurrentContext({ id: 'project-a', type: { id: 'ProjectMaster' }, value: {} });
configurator.serviceDiscovery.addService({ key: 'catalog' });
});
mockFramework initializes every module FrameworkConfigurator declares (event, auth,
http, serviceDiscovery, context, telemetry) with zero configuration — a default signed-in
Test User and offline service resolution out of the box.
Step 3 — Seed the module the test needs
Use references/module-mocks.md for the full per-module table (auth, service discovery, context,
bookmark, feature flag, analytics, telemetry, app manifest) with defaults, builder methods, and
signed-out/token-exact recipes.
Step 4 — Fake HTTP responses
Use references/http-and-openapi-mocks.md to choose between a hand-written
configurator.http.addMiddleware(...), createRouterMiddleware for several routes, or
createOpenApiMockMiddleware (backed by @equinor/fusion-openapi-mock) for a whole OpenAPI
document. An unmatched request always falls through to next(uri, init) and eventually the real
network — a fully offline test must answer every request it expects.
Step 5 — Add a mock for a custom module (when needed)
Use references/custom-module-mocks.md when the module under test is not one of the built-ins —
covers the client seam (setClient), builder-owned configuration, and exposing a
configurator.<yourModule> accessor via FrameworkMockConfigurator's _pin/_getConfig.
Step 6 — Verify
- The mocked boundary is the client only — configurator/provider/validation are real
- Determinism: tokens and resolved services are identical across runs (no
Date.now()-derived assertions without seeding) - Every expected HTTP request has an answering middleware, or the test intentionally allows fallthrough
- Call-level assertions use the test runner's own spy tooling, not an invented Fusion API
Expected output
- Test code that seeds Fusion module state through the correct
/mockentry point - A stated choice of layer (
mockFramework/mockAppModules/ moduleenable*Mock) and why - HTTP faking strategy chosen (hand-written middleware, router, or OpenAPI) and its offline guarantees
- Any custom-module mock wiring, if applicable
Safety & constraints
Never:
- Invent a Fusion-specific mocking API for individual call assertions — that is the test runner's job
- Treat an unsigned mock JWT (
createMockToken/MSAL mock output) as valid outside a test - Replace a module's provider or configurator wholesale when only its client needs faking
- Assume
setResolveUnknownServices(false)is safe without declaring every service the framework itself resolves at start-up (e.g.context)
Always:
- Prefer the smallest mock boundary that still exercises the behavior under test
- Cite the real package/export used (e.g.
enableContextMockfrom@equinor/fusion-framework-module-context/mock) rather than inventing one - Note when a test intentionally allows network fallthrough vs. when it must stay fully offline
FAQ
What does the fusion-framework-mocking skill do?
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.
How do I install fusion-framework-mocking?
Run npx skills add https://github.com/equinor/fusion-skills --skill fusion-framework-mocking in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/fusion-framework-mocking/ (personal) or .claude/skills/fusion-framework-mocking/ (project).
Which AI agents can use fusion-framework-mocking?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is fusion-framework-mocking safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains fusion-framework-mocking?
It is published by equinor in equinor/fusion-skills. It has 94 recorded installs.
More from equinor/fusion-skills
fusion-issue-authoring
equinor/fusion-skills
Classify issue type, activate the matching agent mode for type-specific drafting, and enforce shared safety gates before GitHub mutation.
fusion-github-review-resolution
equinor/fusion-skills
Resolves unresolved GitHub PR review threads end-to-end: evaluates whether each review comment is correct, applies a targeted fix when valid, replies with rationale when not, commits, and resolves the thread. USE FOR: unresolved review threads, PR review feedback, changes requested PRs, PR review URLs (pullrequestreview-...), fix the review comments, close the open threads, address PR feedback. DO NOT USE FOR: summarizing feedback without code changes, creating new PRs, or read-only branches.
fusion-issue-solving
equinor/fusion-skills
Handles GitHub issue resolution end-to-end for prompts like "solve 123", "lets solve 123", "work on 123", "work on https://github.com/owner/repo/issues/123", or by pasting a direct GitHub issue URL as the request. USE FOR: solve 123, continue work on issue 123, work on https://github.com/owner/repo/issues/123, paste a GitHub issue URL for implementation work. DO NOT USE FOR: issue drafting only, PR review only, or non-implementation research.
fusion-code-conventions
equinor/fusion-skills
Applies and explains code conventions across TypeScript, React, C, and Markdown. Enforces naming rules, file naming patterns, TSDoc and XML doc standards, inline comment intent (the why, not the what), code structure, error handling, async patterns, and dead code policy. Also enforces ADR and contributor doc decisions, and flags decisions that appear stale or misaligned with current tooling. USE FOR: convention questions, code review against project standards, applying naming rules, auditing intent comments, checking TSDoc completeness, enforcing recorded ADR decisions, and flagging stale architectural decisions. DO NOT USE FOR: security vulnerability scanning, performance profiling, runtime debugging, or generating net-new code without a review target.
fusion-dependency-review
equinor/fusion-skills
Review dependency PRs with structured research, existing-PR-discussion capture, multi-lens analysis (security, code quality, impact), and a repeatable verdict template. USE FOR: dependency update PRs, Renovate/Dependabot PRs, library upgrade reviews, "review this dependency PR", "should we merge this update". DO NOT USE FOR: feature PRs, application code reviews, dependency automation/bot configuration, or unattended merge without confirmation.
fusion-mcp
equinor/fusion-skills
Explain what Fusion MCP is and guide users through setting it up when they need Fusion-aware MCP capabilities in Copilot workflows.
Popular backend & apis skills
find-skills
vercel-labs/skills
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
entra-app-registration
microsoft/azure-skills
Guides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration. USE FOR: create app registration, register Azure AD app, configure OAuth, set up authentication, add API permissions, generate service principal, MSAL example, console app auth, Entra ID setup, Azure AD authentication. DO NOT USE FOR: Key Vault secrets (use azure-keyvault-expiration-audit), general Azure resource security guidance.
google-agents-cli-adk-code
google/agents-cli
This skill should be used when the user wants to "write agent code", "build an agent with ADK", "add a tool", "create a callback", "define an agent", "use state management" — in a project that needs ADK (Agent Development Kit) API patterns and code examples. It provides a quick reference for agent types, tool definitions, orchestration patterns, callbacks, state management, the graph Workflow API, and reference recipes to study. Do NOT use for scaffolding (use google-agents-cli-scaffold) or deployment (use google-agents-cli-deploy).
embedded-captions
heygen-com/hyperframes
Add captions or subtitles to an existing single-subject talking-head video without editing the footage. Use for plain verbatim captions, cinematic captions embedded behind the subject, VFX captions, “炸/特效/酷炫字幕,” or a named identity from the 35-style catalog. Route by visual identity, not by backend engine. The quiet anchor rail is the default; embed every word only when the user explicitly wants a fully cinematic treatment. The workflow runs locally end to end, including transcription and subject matting; split multi-shot footage before applying it.
entra-agent-id
microsoft/azure-skills
Provision Microsoft Entra Agent Identity Blueprints, BlueprintPrincipals, and per-instance Agent Identities via Microsoft Graph, and configure OAuth 2.0 token exchange (fmipath, OBO, cross-tenant) including the Microsoft Entra SDK for AgentID sidecar. USE FOR: Agent Identity Blueprint, BlueprintPrincipal, agent OAuth, fmipath token exchange, agent OBO, Workload Identity Federation for agents, polyglot agent auth, Microsoft.Identity.Web.AgentIdentities. DO NOT USE FOR: standard Entra app registration (use entra-app-registration), Microsoft Foundry agent authoring (use microsoft-foundry).
neon
neondatabase/agent-skills
Overview of Neon, a complete set of cloud backend primitives around Lakebase Postgres: Auth, Object Storage, Functions, the AI Gateway, and Realtime. Start here to choose Neon for undecided login, files, APIs, and LLM calls, set up the CLI or MCP server, and follow the branch-first workflow. Use when building an app or backend on Neon, or when "Neon" or "Lakebase Postgres" is mentioned. Child skill neon-postgres wins for an existing DATABASEURL, SQL, schema, inspect, or search. Child skill neon-auth wins for login, users, sessions, identity routing, and Managed Better Auth setup. Child skill neon-realtime wins for live queries in reactive apps and agents. Also use for object storage, S3, buckets, serverless functions, function triggers, cron, AI gateway, LLM calls, realtime, logs, Loki, Grafana, observability, postgres, database, backend, Claimable Neon, neon.new, or a no-signup database.