fedi-ui-test-patterns

Guides writing and running unit, integration, and Appium e2e tests for Fedi UI workspaces.

78|27|Updated May 4, 2024
One-click install
npx skills add https://github.com/fedixyz/fedi --skill fedi-ui-test-patterns-fedixyz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fedi-ui-test-patterns
Source: https://github.com/fedixyz/fedi/tree/main/.agents/skills/fedi-ui-test-patterns
Command: npx skills add https://github.com/fedixyz/fedi --skill fedi-ui-test-patterns-fedixyz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Choosing the right test type, environment, and conventions across Fedi's three UI workspaces (common, native, web) is error-prone; this Skill routes you to the correct patterns, mock builders, and run scripts so tests match existing suites. ## Core Features & Use Cases - Test-type decision guide: Routes work to unit, integration, or Appium e2e tests based on whether the change touches hooks, utilities, bridge RPCs, or navigation flows. - Environment-specific pattern references: Dedicated guides for ui/common, ui/native, and ui/web covering render helpers, provider-heavy vs providerless tests, and canonical example files. - Mock builder catalog: Documents createMockFedimintBridge, transaction/federation/Matrix event factories, and integration test builders like withFederationJoined and withEcashReceived. - Use Case: When adding a hook to ui/common that calls the real bridge, the Skill directs you to integration patterns, the IntegrationTestBuilder state helpers, and the correct run script (./scripts/ui/run-integration-tests.sh). ## Quick Start Ask the assistant to write a unit test for a specific hook or component in ui/native, ui/web, or ui/common and it will select the right patterns and mocks.

Frequently Asked Questions about fedi-ui-test-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a unit test for a React Native screen in Fedi?

Use renderWithProviders from ui/native/tests/utils/render.tsx, pass mockNavigation and mockRoute from jest.setup.mocks.ts, and query with @testing-library/react-native. Call jest.clearAllMocks() in beforeEach and cleanup() in afterEach, following ui/native/tests/unit/screens/ShareLogs.test.tsx.

How do I run Fedi UI unit and integration tests?

Always use the top-level scripts: ./scripts/ui/run-unit-tests.sh or ./scripts/ui/run-integration-tests.sh, optionally with a workspace name (common, native, web) and a specific test file. For e2e, use ./scripts/ui/run-e2e.sh or the platform-specific Android/iOS variants.

When should I write an integration test instead of a unit test?

Write integration tests when the change involves hooks calling the real bridge via useFedimint, Redux dispatches triggering bridge RPCs, Matrix chat flows, or end-to-end data flows. Unit tests mock the bridge entirely and suit pure utilities, selectors, and prop-driven rendering.

Does createMockFedimintBridge provide default RPC responses?

No. Only methods you explicitly name exist on the mock; unmocked direct calls throw TypeError while rpcResult returns ok(undefined). Never add defaults to the shared factory, since that would silently answer for every test in the repo.

Why is my Appium e2e test not running in CI?

New tests must be registered in four places: registry.ts, the e2e-tests.yml workflow_dispatch options, run-e2e.sh, and e2e-pipeline.sh if the test needs the devimint federation. Missing any one silently drops the test from that entry point.

When should I not write a test for a UI change?

Skip tests for pure styling changes that don't affect important element positioning, simple prop-passing components with no logic, one-off configuration changes, and changes already covered by existing tests. The Fedi team follows a pragmatic testing approach.