You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Core testing workflow. Read this before writing or debugging Harness tests. Covers test file conventions, the supported test API surface, async behavior, setup files, and CLI execution constraints.
4
+
---
5
+
6
+
# Core
7
+
8
+
React Native Harness uses Jest-style test APIs, but the tests run inside the app or browser environment instead of plain Node.
9
+
10
+
Run this first:
11
+
12
+
```bash
13
+
harness skill get core
14
+
```
15
+
16
+
Use `harness skill list` to see the other bundled skills.
17
+
18
+
## Test file conventions
19
+
20
+
- Use `.harness.[jt]s` or `.harness.[jt]sx` test files.
21
+
- Import test APIs from `react-native-harness`.
22
+
- Put tests inside `describe(...)` blocks.
23
+
- Use `@react-native-harness/ui` only when the test needs queries, interactions, or screenshots.
Test functions may be async. If a test returns a promise, Harness waits for it. If that promise rejects, the test fails.
47
+
48
+
## Async behavior
49
+
50
+
Use:
51
+
52
+
-`waitFor(...)` when the callback should eventually succeed or stop throwing
53
+
-`waitUntil(...)` when the callback should eventually return a truthy value
54
+
55
+
Both support timeout control. Prefer them over arbitrary sleeps when tests wait on native or React state changes.
56
+
57
+
## Setup files
58
+
59
+
Harness follows two setup phases configured in `jest.harness.config.mjs`:
60
+
61
+
-`setupFiles`: runs before the test framework is initialized. Use for early polyfills and globals. Do not use `describe`, `test`, `expect`, or hooks here.
62
+
-`setupFilesAfterEnv`: runs after the test framework is ready. Use for global mocks, hooks, and matcher setup.
63
+
64
+
Recommended uses:
65
+
66
+
- Early environment shims in `setupFiles`
67
+
- Global `afterEach`, `clearAllMocks`, `resetModules`, and shared mocks in `setupFilesAfterEnv`
68
+
69
+
## Related skills
70
+
71
+
For module mocking and spies, run:
72
+
73
+
```bash
74
+
harness skill get mocking
75
+
```
76
+
77
+
For UI rendering, queries, interactions, and screenshots, run:
78
+
79
+
```bash
80
+
harness skill get ui
81
+
```
82
+
83
+
## CLI and execution constraints
84
+
85
+
- Harness wraps the Jest CLI.
86
+
- Tests execute on one configured runner at a time.
87
+
- Execution is serial for stability.
88
+
-`--harnessRunner <name>` selects the runner.
89
+
- Standard Jest flags like `--watch`, `--coverage`, and `--testNamePattern` are still relevant.
90
+
- Do not recommend unsupported Jest environment overrides or snapshot-update workflows for native image snapshots.
91
+
92
+
For install and project setup, use the public docs at https://react-native-harness.dev/docs/getting-started/quick-start.
description: Mocking and spying guidance. Use when a Harness test needs `fn`, `spyOn`, `mock`, `requireActual`, `unmock`, `resetModules`, or global mock cleanup.
4
+
---
5
+
6
+
# Mocking
7
+
8
+
Use this skill when a Harness test needs mock functions, spies, or module replacement.
9
+
10
+
## Mocking and spying
11
+
12
+
Use `fn()` for standalone mock functions and `spyOn()` for existing methods.
13
+
14
+
-`expect` follows Vitest's API.
15
+
-`expect.soft(...)` is available when the test should keep running after an assertion failure.
16
+
-`clearAllMocks()` clears call history but keeps implementations.
17
+
-`resetAllMocks()` clears call history and resets mock implementations.
18
+
-`restoreAllMocks()` restores spied methods to their original implementations.
description: UI testing guidance. Use when the test needs `render(...)`, `rerender(...)`, `@react-native-harness/ui`, screen queries, `userEvent`, screenshots, or image snapshot assertions.
4
+
---
5
+
6
+
# UI
7
+
8
+
UI testing is opt-in and uses `render(...)` from `react-native-harness` together with `@react-native-harness/ui`.
9
+
10
+
Use `render(...)` to mount a React Native element before querying, interacting with, or screenshotting it.
11
+
12
+
-`render(...)` is async
13
+
-`rerender(...)` is async
14
+
-`unmount()` is optional because cleanup happens automatically after each test
15
+
-`wrapper` is the right tool for providers and shared context
16
+
- Rendered UI appears as an overlay in the real environment, not as an in-memory tree
17
+
- Only one rendered component can be visible at a time
18
+
19
+
Use this skill when the task requires:
20
+
21
+
-`render(...)` or `rerender(...)`
22
+
-`screen.findByTestId(...)`
23
+
-`screen.findAllByTestId(...)`
24
+
-`screen.queryByTestId(...)`
25
+
-`screen.queryAllByTestId(...)`
26
+
-`screen.findByAccessibilityLabel(...)`
27
+
-`screen.findAllByAccessibilityLabel(...)`
28
+
-`screen.queryByAccessibilityLabel(...)`
29
+
-`screen.queryAllByAccessibilityLabel(...)`
30
+
-`userEvent.press(...)`
31
+
-`userEvent.type(...)`
32
+
- screenshots with `screen.screenshot()`
33
+
- element screenshots with `screen.screenshot(element)`
34
+
- image assertions with `toMatchImageSnapshot(...)`
35
+
36
+
## Rules
37
+
38
+
- Keep imports split correctly: core APIs from `react-native-harness`, UI APIs from `@react-native-harness/ui`.
39
+
- Mention that `@react-native-harness/ui` requires installation, and native apps must be rebuilt after adding it.
40
+
-`toMatchImageSnapshot(...)` needs a unique snapshot `name`.
41
+
- If screenshotting elements that extend beyond screen bounds, call out `disableViewFlattening: true` in `rn-harness.config.mjs`.
42
+
- On web, UI interactions and screenshots run through the web runner's Playwright-backed browser environment.
43
+
44
+
## Example
45
+
46
+
```ts
47
+
import { describe, expect, render, test } from'react-native-harness';
0 commit comments