Write and review JavaScript and TypeScript Jest tests with strong structure, mocks, async handling, snapshots, and React Testing Library patterns. Use this skill when the user asks to add Jest tests, improve test structure, mock APIs or databases, test async code, update snapshots, or test React components.
Write focused JavaScript and TypeScript Jest tests by selecting file placement, isolation boundaries, matcher style, async handling, and React Testing Library queries, then return a runnable test plan or test implementation summary.
Use this for JavaScript/TypeScript test work where Jest is the runner.
When to invoke
"Add Jest tests for this TypeScript module."
"How should I mock this API in Jest?"
"Review this test structure and matchers."
"Fix this async Jest test."
"Write React component tests with Testing Library."
Test placement and structure
Concern
Rule
Example
File names
Name test files with .test.ts or .test.js suffix. Use .test.tsx or .test.jsx for JSX when the project uses those extensions.
calculator.test.ts, SearchBox.test.tsx
Location
Place tests next to the code they test or in a dedicated __tests__ directory; follow the repository's existing convention.
src/foo.test.ts or src/__tests__/foo.test.ts
Names
Use descriptive test names that explain expected behavior, not implementation mechanics.
it('returns an empty list when the API has no results', ...)
Grouping
Use nested describe blocks only when they add signal around a component, function, class, method, or state.
Follow describe('Component/Function/Class', () => { it('should do something', () => {}) }) when no local style is stronger.
Keep setup near the assertions it supports.
Prefer arrange-act-assert within each test. Keep one behavioral reason to fail per test; split tests when the assertion list starts describing multiple scenarios.
Mocking and isolation
Need
Jest primitive
Guidance
Replace a module for the whole file
jest.mock()
Mock external dependencies such as APIs, databases, queues, file systems, clocks, and network clients to isolate the unit under test.
Observe or override one exported function or object method
jest.spyOn()
Restore spies after the test, especially for globals such as Date, console, fetch, or Math.random.
Define dynamic behavior
mockImplementation()
Use when return values depend on arguments or call order.
Define a simple fixed value
mockReturnValue()
Use for deterministic sync collaborators.
Reset cross-test state
jest.resetAllMocks() in afterEach
Reset mocks between tests when implementations or call histories are test-specific. Use jest.clearAllMocks() when implementations should remain but call counts should reset.
Mock at the boundary you own. Do not mock the function under test. If a mock becomes more complex than the behavior it replaces, prefer an in-memory fake or a higher-level integration test.
Treat jest.mock() as the module-level replacement tool; use narrower spies only when the real module should remain loaded.
Async code and timers
Pattern
Correct test style
Failure to avoid
Promise resolves
await expect(promise).resolves.toEqual(value)
Missing return or await, which lets the test pass before the promise settles.
Promise rejects
await expect(promise).rejects.toThrow(Error)
Wrapping an async call in expect(() => asyncFn()).toThrow().
Async arrange/act
const result = await subject()
Mixing done callbacks with promises unless testing callback APIs.
Slow integration path
jest.setTimeout(ms)
Raising timeouts for unit tests instead of removing real I/O.
Timers
Use fake timers only when the behavior depends on time.
Forgetting to advance timers and flush pending promises.
Always return promises or use async/await syntax in tests. A test that schedules work without awaiting it is not testing the scheduled behavior.
Use jest.setTimeout() deliberately and document why the test is legitimately slow.
Snapshots and React components
Use snapshot tests for UI components or complex objects that change infrequently and are hard to assert field-by-field.
Keep snapshots small and focused; avoid snapshotting entire application trees.
Review snapshot changes carefully before committing; a snapshot update is an assertion change.
Use React Testing Library over Enzyme for testing components.
Test user behavior and component accessibility instead of component internals.
Query elements by accessibility roles, labels, or text content before falling back to test IDs.
Use userEvent over fireEvent for realistic user interactions.
The output reports the command run or states why validation was not run.
1---2name: javascript-typescript-jest-33description: Write and review JavaScript and TypeScript Jest tests with strong structure, mocks, async handling, snapshots, and React Testing Library patterns. Use this skill when the user asks to add Jest tests, improve test structure, mock APIs or databases, test async code, update snapshots, or test React components.4---56<!-- Generated from harness/github-copilot/plugins/testing-automation/skills/javascript-typescript-jest/SKILL.md by harness/claude-code/scripts/convert_from_copilot.py. Edit the source, not this file. -->78# JavaScript TypeScript Jest910Write focused JavaScript and TypeScript Jest tests by selecting file placement, isolation boundaries, matcher style, async handling, and React Testing Library queries, then return a runnable test plan or test implementation summary.1112Use this for JavaScript/TypeScript test work where Jest is the runner.1314## When to invoke1516- "Add Jest tests for this TypeScript module."17- "How should I mock this API in Jest?"18- "Review this test structure and matchers."19- "Fix this async Jest test."20- "Write React component tests with Testing Library."2122## Test placement and structure2324| Concern | Rule | Example |25| --- | --- | --- |26| File names | Name test files with `.test.ts` or `.test.js` suffix. Use `.test.tsx` or `.test.jsx` for JSX when the project uses those extensions. | `calculator.test.ts`, `SearchBox.test.tsx` |27| Location | Place tests next to the code they test or in a dedicated `__tests__` directory; follow the repository's existing convention. | `src/foo.test.ts` or `src/__tests__/foo.test.ts` |28| Names | Use descriptive test names that explain expected behavior, not implementation mechanics. | `it('returns an empty list when the API has no results', ...)` |29| Grouping | Use nested `describe` blocks only when they add signal around a component, function, class, method, or state. | `describe('UserService', () => { describe('createUser', () => { ... }) })` |30| Shape | Follow `describe('Component/Function/Class', () => { it('should do something', () => {}) })` when no local style is stronger. | Keep setup near the assertions it supports. |3132Prefer arrange-act-assert within each test. Keep one behavioral reason to fail per test; split tests when the assertion list starts describing multiple scenarios.3334## Mocking and isolation3536| Need | Jest primitive | Guidance |37| --- | --- | --- |38| Replace a module for the whole file | `jest.mock()` | Mock external dependencies such as APIs, databases, queues, file systems, clocks, and network clients to isolate the unit under test. |39| Observe or override one exported function or object method | `jest.spyOn()` | Restore spies after the test, especially for globals such as `Date`, `console`, `fetch`, or `Math.random`. |40| Define dynamic behavior | `mockImplementation()` | Use when return values depend on arguments or call order. |41| Define a simple fixed value | `mockReturnValue()` | Use for deterministic sync collaborators. |42| Reset cross-test state | `jest.resetAllMocks()` in `afterEach` | Reset mocks between tests when implementations or call histories are test-specific. Use `jest.clearAllMocks()` when implementations should remain but call counts should reset. |4344Mock at the boundary you own. Do not mock the function under test. If a mock becomes more complex than the behavior it replaces, prefer an in-memory fake or a higher-level integration test.4546Treat `jest.mock()` as the module-level replacement tool; use narrower spies only when the real module should remain loaded.4748## Async code and timers4950| Pattern | Correct test style | Failure to avoid |51| --- | --- | --- |52| Promise resolves | `await expect(promise).resolves.toEqual(value)` | Missing `return` or `await`, which lets the test pass before the promise settles. |53| Promise rejects | `await expect(promise).rejects.toThrow(Error)` | Wrapping an async call in `expect(() => asyncFn()).toThrow()`. |54| Async arrange/act | `const result = await subject()` | Mixing `done` callbacks with promises unless testing callback APIs. |55| Slow integration path | `jest.setTimeout(ms)` | Raising timeouts for unit tests instead of removing real I/O. |56| Timers | Use fake timers only when the behavior depends on time. | Forgetting to advance timers and flush pending promises. |5758Always return promises or use async/await syntax in tests. A test that schedules work without awaiting it is not testing the scheduled behavior.5960Use `jest.setTimeout()` deliberately and document why the test is legitimately slow.6162## Snapshots and React components6364- Use snapshot tests for UI components or complex objects that change infrequently and are hard to assert field-by-field.65- Keep snapshots small and focused; avoid snapshotting entire application trees.66- Review snapshot changes carefully before committing; a snapshot update is an assertion change.67- Use React Testing Library over Enzyme for testing components.68- Test user behavior and component accessibility instead of component internals.69- Query elements by accessibility roles, labels, or text content before falling back to test IDs.70- Use `userEvent` over `fireEvent` for realistic user interactions.7172## Common Jest matchers7374| Category | Matchers |75| --- | --- |76| Basic identity and equality | `expect(value).toBe(expected)`, `expect(value).toEqual(expected)` |77| Truthiness | `expect(value).toBeTruthy()`, `expect(value).toBeFalsy()` |78| Numbers | `expect(value).toBeGreaterThan(3)`, `expect(value).toBeLessThanOrEqual(3)` |79| Strings | `expect(value).toMatch(/pattern/)`, `expect(value).toContain('substring')` |80| Arrays | `expect(array).toContain(item)`, `expect(array).toHaveLength(3)` |81| Objects | `expect(object).toHaveProperty('key', value)` |82| Exceptions | `expect(fn).toThrow()`, `expect(fn).toThrow(Error)` |83| Mock functions | `expect(mockFn).toHaveBeenCalled()`, `expect(mockFn).toHaveBeenCalledWith(arg1, arg2)` |8485## Output template8687```markdown88## Jest test result8990**Status:** implemented | reviewed | blocked91**Target:** `<file, component, function, or class>`9293| Area | Decision | Evidence |94| --- | --- | --- |95| Structure | `<placement and describe/it shape>` | `<test path or planned path>` |96| Mocking | `<jest.mock / jest.spyOn / fake / none>` | `<dependency boundary>` |97| Async | `<await/resolves/rejects/timers/not applicable>` | `<specific behavior>` |98| Assertions | `<matcher choices>` | `<key expectations>` |99100**Validation**101- `<test command>`: pass | fail | not run102```103104## Quality gate105106- [ ] Test files use the repository's placement convention and a valid `.test.ts`, `.test.js`, `.test.tsx`, or `.test.jsx` suffix.107- [ ] Test names describe observable behavior.108- [ ] External dependencies are mocked or faked at the boundary, not inside the subject.109- [ ] Mocks are reset, cleared, or restored between tests according to how they are configured.110- [ ] Promise-based behavior is returned or awaited, including `resolves` and `rejects` assertions.111- [ ] Snapshot tests are small, intentional, and reviewed as assertion changes.112- [ ] React component tests prefer React Testing Library, accessible queries, and `userEvent`.113- [ ] The output reports the command run or states why validation was not run.
Run npx skillmds@latest add paulasilvatech/javascript-typescript-jest-3 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Write and review JavaScript and TypeScript Jest tests with strong structure, mocks, async handling, snapshots, and React Testing Library patterns. Use this skill when the user asks to add Jest tests, improve test structure, mock APIs or databases, test async code, update snapshots, or test React components. It is listed under Web & Frontend on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
paulasilvatech (@paulasilvatech) published this skill. Their other Agent Skills are listed on their SkillMD profile.
paulasilvatech