
writing-tests
Analyze existing code and write comprehensive unit and integration tests for it. Detects the test framework, identifies untested code paths, and generates tests with proper mocking, edge cases, and assertions. Use when the user asks to add tests, improve coverage, or test a specific module.
- Installs
- 504
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill writing-tests- 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 writing-tests 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.
Writing Tests
Use this skill when the user asks to add tests to existing code, improve test coverage, or write tests for a specific file or module.
Steps
-
Detect the test setup — check what's already configured:
# Check package.json for test runner cat package.json | grep -E "jest|vitest|mocha|playwright|cypress"Look for config files:
vitest.config.ts,jest.config.ts,playwright.config.ts,.mocharc.*. Check for existing test files to understand the project's test patterns and conventions. -
If no test runner exists — set one up:
npm install -D vitest @testing-library/react @testing-library/jest-domAdd a
testscript topackage.json:{ "test": "vitest run", "test:watch": "vitest" } -
Analyze the target code — read the file(s) to test and identify:
- Public API: exported functions, classes, components, hooks
- Code paths: conditionals, error handling, edge cases
- Dependencies: external services, databases, APIs that need mocking
- Side effects: file I/O, network calls, DOM mutations
-
Create the test file — place it next to the source file or in a
__tests__/directory, matching the project's convention:src/utils/format.ts→src/utils/format.test.tssrc/components/Button.tsx→src/components/Button.test.tsx
-
Write tests following this structure:
import { describe, it, expect, vi } from "vitest"; describe("functionName", () => { // Happy path it("returns formatted output for valid input", () => { ... }); // Edge cases it("handles empty string", () => { ... }); it("handles null/undefined input", () => { ... }); // Error cases it("throws on invalid argument", () => { ... }); // Boundary conditions it("handles maximum length input", () => { ... }); }); -
Mock external dependencies — don't make real API calls or database queries in unit tests:
vi.mock("@/lib/db", () => ({ query: vi.fn().mockResolvedValue([{ id: 1, name: "test" }]), }));For React components, mock hooks that fetch data:
vi.mock("@/hooks/useUser", () => ({ useUser: () => ({ user: { name: "Test" }, isLoading: false }), })); -
Test React components with Testing Library:
import { render, screen, fireEvent } from "@testing-library/react"; it("renders the button and handles click", () => { const onClick = vi.fn(); render(<Button onClick={onClick}>Click me</Button>); fireEvent.click(screen.getByRole("button", { name: "Click me" })); expect(onClick).toHaveBeenCalledOnce(); }); -
Run the tests and verify they pass:
npm testIf any fail, fix the test or the code (depending on whether the test expectation or the implementation is wrong).
What to Test
- Always test: public API, error handling, edge cases (empty, null, zero, negative), state transitions, async behavior
- Skip testing: private implementation details, third-party library internals, simple getters/setters, type-only code
Notes
- Match the project's existing test style — if they use
test()instead ofit(), follow that. - Don't test implementation details — test behavior and outputs, not internal method calls.
- Use descriptive test names that explain the scenario: "returns 0 when cart is empty" not "test1".
- One assertion concept per test — multiple
expectcalls are fine if they verify the same behavior. - For async code, always
awaitthe result or useresolves/rejectsmatchers.
FAQ
What does the writing-tests skill do?
Analyze existing code and write comprehensive unit and integration tests for it. Detects the test framework, identifies untested code paths, and generates tests with proper mocking, edge cases, and assertions. Use when the user asks to add tests, improve coverage, or test a specific module.
How do I install writing-tests?
Run npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill writing-tests 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/writing-tests/ (personal) or .claude/skills/writing-tests/ (project).
Which AI agents can use writing-tests?
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 writing-tests 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 writing-tests?
It is published by spencerpauly in spencerpauly/awesome-cursor-skills. It has 504 recorded installs.
More from spencerpauly/awesome-cursor-skills
visual-qa-testing
spencerpauly/awesome-cursor-skills
Visually QA a web application by launching it in Cursor's built-in browser, taking screenshots, checking console errors, and auditing network requests. Use after making UI changes to verify they look correct.
auditing-security
spencerpauly/awesome-cursor-skills
Perform a systematic security audit of a codebase, checking for OWASP Top 10 vulnerabilities, secrets exposure, and insecure patterns.
responsive-testing
spencerpauly/awesome-cursor-skills
Open the app in Cursor's browser at multiple viewport sizes, screenshot each, and report any layout breakage.
suggesting-cursor-rules
spencerpauly/awesome-cursor-skills
When the user repeats the same correction or convention multiple times, suggest a Cursor rule to encode it permanently.
systematic-debugging
spencerpauly/awesome-cursor-skills
Structured debugging methodology — reproduce, isolate, hypothesize, verify. Covers git bisect, binary search, logging, and minimal reproduction.
grinding-until-pass
spencerpauly/awesome-cursor-skills
Keep iterating on code changes until the tests pass, the build succeeds, or linting is clean. Runs in a tight loop of fix → run → check → repeat. Use when you want the agent to autonomously grind through test failures or build errors.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work