spencerpauly/awesome-cursor-skills

writing-tests

Analyze existing code and write comprehensive unit and integration tests for it.

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill writing-tests

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

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:
bash
   # 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.

  1. If no test runner exists — set one up:
bash
   npm install -D vitest @testing-library/react @testing-library/jest-dom

Add a test script to package.json:

json
   { "test": "vitest run", "test:watch": "vitest" }
  1. 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
  1. 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.ts
  • src/components/Button.tsx → src/components/Button.test.tsx
  1. Write tests following this structure:
ts
   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", () => { ... });
   });
  1. Mock external dependencies — don't make real API calls or database queries in unit tests:
ts
   vi.mock("@/lib/db", () => ({
     query: vi.fn().mockResolvedValue([{ id: 1, name: "test" }]),
   }));

For React components, mock hooks that fetch data:

ts
   vi.mock("@/hooks/useUser", () => ({
     useUser: () => ({ user: { name: "Test" }, isLoading: false }),
   }));
  1. Test React components with Testing Library:
tsx
   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();
   });
  1. Run the tests and verify they pass:
bash
   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.

관련 작업

같은 저장소의 Skills

더 많은 Skills

모든 Skills