Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
spencerpauly avatar

Writing Tests

  • 280 installs
  • 655 repo stars
  • Updated August 2, 2026
  • spencerpauly/awesome-cursor-skills

Helps with testing & qa tasks.

About

writing-tests is a Claude Code skill for testing & qa. It helps solo builders move faster with AI-assisted coding.

  • writing-tests
  • Testing & QA
  • AI-coding skill

Writing Tests by the numbers

  • 280 all-time installs (skills.sh)
  • +31 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #728 of 2,153 Testing & QA skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill writing-tests

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs280
repo stars655
Last updatedAugust 2, 2026
Repositoryspencerpauly/awesome-cursor-skills

What it does

Helps with testing & qa tasks.

Files

SKILL.mdMarkdownGitHub ↗

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

1. 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.

2. If no test runner exists — set one up:

   npm install -D vitest @testing-library/react @testing-library/jest-dom

Add a test script to package.json:

   { "test": "vitest run", "test:watch": "vitest" }

3. 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

4. Create the test file — place it next to the source file or in a __tests__/ directory, matching the project's convention:

  • src/utils/format.tssrc/utils/format.test.ts
  • src/components/Button.tsxsrc/components/Button.test.tsx

5. 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", () => { ... });
   });

6. 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 }),
   }));

7. 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();
   });

8. Run the tests and verify they pass:

   npm test

If 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 of it(), 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 expect calls are fine if they verify the same behavior.
  • For async code, always await the result or use resolves/rejects matchers.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.