본문으로 건너뛰기
cccskills
무료GitHub에 공개한국어 소개

write-frontend-tests

현재 브랜치의 프런트엔드 변경에서 테스트 대상을 고르고 계획 확인 후 화면 조작과 API 응답을 검증하는 통합 테스트를 작성합니다. 실행과 서식·타입 검사도 진행합니다.

원문원문 설명 보기

Analyze the current branch diff against dev, plan integration tests for changed frontend pages/components, and write them. TRIGGER when user asks to write frontend tests, add test coverage, or 'write tests for my changes'.

AI 평가90점/ 100설치 방법 보기

이럴 때 유용합니다

  • 현재 화면 변경에 테스트 추가
  • 로딩·오류·빈 데이터 화면 검증
  • 폼과 모달의 조작 테스트
  • 변경된 동작에 맞춰 기존 테스트 갱신

한국어 소개

할 수 있는 일

현재 브랜치와 기준 브랜치의 차이를 살펴 변경한 프런트엔드 페이지와 컴포넌트의 통합 테스트를 계획하고 작성합니다. 통합 테스트는 화면 표시, 사용자 조작, 데이터 가져오기를 함께 확인합니다. MSW로 API 응답을 모의해 정상 응답, 로딩, 오류, 빈 데이터 상태 등을 검증합니다. 기존 테스트의 추가나 갱신 여부도 판단합니다.

이럴 때 유용합니다

화면의 데이터 가져오기나 조작 방식을 변경한 뒤 테스트를 어디에 추가할지 정리할 때 유용합니다. 페이지를 우선하며 복잡한 폼과 모달도 대상으로 합니다. 외관, 타입, 설정만 바뀐 경우는 제외합니다.

사용 예시

  • “이 브랜치의 프런트엔드 변경에 테스트를 추가해 주세요.”
  • “dev와의 차이를 보고 테스트 계획을 작성해 주세요.”
  • “목록 화면의 오류 상태와 빈 데이터 표시를 검증해 주세요.”

주의 사항

기준 브랜치의 기본값은 dev입니다. 코드 작성 전에 테스트 계획을 제시하고 사용자 확인을 기다립니다. AutoGPT의 프런트엔드 구성과 기존 테스트 규칙, 전용 렌더링 도우미, MSW 설정을 전제로 합니다. pnpm으로 테스트를 실행한 뒤 서식 정리, 린트, 타입 검사도 수행합니다.

이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.

객관 평가

AI가 SKILL.md의 내용만을 근거로 4가지 관점에서 판정했습니다. 스타 수나 인기도는 판정에 넣지 않았습니다.

지시의 명확성언제 쓰고 무엇을 하는지 알 수 있는가
A양호현재 브랜치 변경으로 프런트엔드 테스트를 계획하는 상황과 대상 선정 기준이 명시되어 있습니다.
절차의 구체성절차·입출력·예시가 구체적으로 적혀 있는가
A양호차이 확인부터 실행까지 일곱 단계이며 계획, 테스트 코드, 파일 위치와 검증 명령 예시가 있습니다.
안전성전송·삭제·명령 실행 등을 명시하고 있는가
A양호코드 작성 전 계획 확인을 기다리고 MSW로 API를 모의하며 실행할 검증 명령을 명시합니다.
도입의 용이성필요한 도구나 API 키가 적고 적혀 있는가
B일부 부족전용 렌더링 도우미, MSW 설정과 pnpm이 필요하지만 설치 및 구성 절차는 없습니다.

총점은 각 항목을 A=25점, B=15점, C=5점으로 더한 값입니다. 2026년 10월 23일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.

평가가 다르다고 생각되면 재검토를 요청하기

어느 항목이 왜 다르다고 생각하는지 적어 주세요. 로그인은 필요 없습니다. SKILL.md와 대조해 평가를 다시 만들고 이곳에 반영합니다.

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

포함된 파일(1)

  • SKILL.md7.3 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Write Frontend Tests

Analyze the current branch's frontend changes, plan integration tests, and write them.

References

Before writing any tests, read the testing rules and conventions:

  • autogpt_platform/frontend/TESTING.md — testing strategy, file locations, examples
  • autogpt_platform/frontend/src/tests/AGENTS.md — detailed testing rules, MSW patterns, decision flowchart
  • autogpt_platform/frontend/src/tests/integrations/test-utils.tsx — custom render with providers
  • autogpt_platform/frontend/src/tests/integrations/vitest.setup.tsx — MSW server setup

Step 1: Identify changed frontend files

BASE_BRANCH="${ARGUMENTS:-dev}"
cd autogpt_platform/frontend

# Get changed frontend files (excluding generated, config, and test files)
git diff "$BASE_BRANCH"...HEAD --name-only -- src/ \
  | grep -v '__generated__' \
  | grep -v '__tests__' \
  | grep -v '\.test\.' \
  | grep -v '\.stories\.' \
  | grep -v '\.spec\.'

Also read the diff to understand what changed:

git diff "$BASE_BRANCH"...HEAD --stat -- src/
git diff "$BASE_BRANCH"...HEAD -- src/ | head -500

Step 2: Categorize changes and find test targets

For each changed file, determine:

  1. Is it a page? (page.tsx) — these are the primary test targets
  2. Is it a hook? (use*.ts) — test via the page/component that uses it; avoid direct renderHook() tests unless it is a shared reusable hook with standalone business logic
  3. Is it a component? (.tsx in components/) — test via the parent page unless it's complex enough to warrant isolation
  4. Is it a helper? (helpers.ts, utils.ts) — unit test directly if pure logic

Priority order:

  1. Pages with new/changed data fetching or user interactions
  2. Components with complex internal logic (modals, forms, wizards)
  3. Shared hooks with standalone business logic when UI-level coverage is impractical
  4. Pure helper functions

Skip: styling-only changes, type-only changes, config changes.

Step 3: Check for existing tests

For each test target, check if tests already exist:

# For a page at src/app/(platform)/library/page.tsx
ls src/app/\(platform\)/library/__tests__/ 2>/dev/null

# For a component at src/app/(platform)/library/components/AgentCard/AgentCard.tsx
ls src/app/\(platform\)/library/components/AgentCard/__tests__/ 2>/dev/null

Note which targets have no tests (need new files) vs which have tests that need updating.

Step 4: Identify API endpoints used

For each test target, find which API hooks are used:

# Find generated API hook imports in the changed files
grep -rn 'from.*__generated__/endpoints' src/app/\(platform\)/library/
grep -rn 'use[A-Z].*V[12]' src/app/\(platform\)/library/

For each API hook found, locate the corresponding MSW handler:

# If the page uses useGetV2ListLibraryAgents, find its MSW handlers
grep -rn 'getGetV2ListLibraryAgents.*Handler' src/app/api/__generated__/endpoints/library/library.msw.ts

List every MSW handler you will need (200 for happy path, 4xx for error paths).

Step 5: Write the test plan

Before writing code, output a plan as a numbered list:

Test plan for [branch name]:

1. src/app/(platform)/library/__tests__/main.test.tsx (NEW)
   - Renders page with agent list (MSW 200)
   - Shows loading state
   - Shows error state (MSW 422)
   - Handles empty agent list

2. src/app/(platform)/library/__tests__/search.test.tsx (NEW)
   - Filters agents by search query
   - Shows no results message
   - Clears search

3. src/app/(platform)/library/components/AgentCard/__tests__/AgentCard.test.tsx (UPDATE)
   - Add test for new "duplicate" action

Present this plan to the user. Wait for confirmation before proceeding. If the user has feedback, adjust the plan.

Step 6: Write the tests

For each test file in the plan, follow these conventions:

File structure

import { render, screen, waitFor } from "@/tests/integrations/test-utils";
import { server } from "@/mocks/mock-server";
// Import MSW handlers for endpoints the page uses
import {
  getGetV2ListLibraryAgentsMockHandler200,
  getGetV2ListLibraryAgentsMockHandler422,
} from "@/app/api/__generated__/endpoints/library/library.msw";
// Import the component under test
import LibraryPage from "../page";

describe("LibraryPage", () => {
  test("renders agent list from API", async () => {
    server.use(getGetV2ListLibraryAgentsMockHandler200());

    render(<LibraryPage />);

    expect(await screen.findByText(/all workflows/i)).toBeDefined();
  });

  test("shows error state on API failure", async () => {
    server.use(getGetV2ListLibraryAgentsMockHandler422());

    render(<LibraryPage />);

    expect(await screen.findByText(/error/i)).toBeDefined();
  });
});

Rules

  • Use render() from @/tests/integrations/test-utils (NOT from @testing-library/react directly)
  • Use server.use() to set up MSW handlers BEFORE rendering
  • Use findBy* (async) for elements that appear after data fetching — NOT getBy*
  • Use getBy* only for elements that are immediately present in the DOM
  • Use screen queries — do NOT destructure from render()
  • Use waitFor when asserting side effects or state changes after interactions
  • Import fireEvent or userEvent from the test-utils for interactions
  • Do NOT mock internal hooks or functions — mock at the API boundary via MSW
  • Prefer Orval-generated MSW handlers and response builders over hand-built API response objects
  • Do NOT use act() manually — render and fireEvent handle it
  • Keep tests focused: one behavior per test
  • Use descriptive test names that read like sentences

Test location

# For pages: __tests__/ next to page.tsx
src/app/(platform)/library/__tests__/main.test.tsx

# For complex standalone components: __tests__/ inside component folder
src/app/(platform)/library/components/AgentCard/__tests__/AgentCard.test.tsx

# For pure helpers: co-located .test.ts
src/app/(platform)/library/helpers.test.ts

Custom MSW overrides

When the auto-generated faker data is not enough, override with specific data:

import { http, HttpResponse } from "msw";

server.use(
  http.get("http://localhost:3000/api/proxy/api/v2/library/agents", () => {
    return HttpResponse.json({
      agents: [{ id: "1", name: "Test Agent", description: "A test agent" }],
      pagination: { total_items: 1, total_pages: 1, page: 1, page_size: 10 },
    });
  }),
);

Use the proxy URL pattern: http://localhost:3000/api/proxy/api/v{version}/{path} — this matches the MSW base URL configured in orval.config.ts.

Step 7: Run and verify

After writing all tests:

cd autogpt_platform/frontend
pnpm test:unit --reporter=verbose

If tests fail:

  1. Read the error output carefully
  2. Fix the test (not the source code, unless there is a genuine bug)
  3. Re-run until all pass

Then run the full checks:

pnpm format
pnpm lint
pnpm types

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

open-pr

무료요약 있음AI 평가 90점

코드 변경의 테스트와 기존 기능에 미치는 영향을 확인하고 저장소 템플릿에 맞춰 PR을 생성하며, 리뷰 요청부터 지적 사항 대응까지 진행합니다.

  • 지정된 템플릿으로 PR 생성
  • 기존 동작과 새 기능의 테스트 확인
  • 로컬 검증이 어려울 때 봇 리뷰 요청
Significant-Gravitas/AutoGPT18.8만2026년 10월 23일 업데이트

orchestrate

무료요약 있음AI 평가 70점

별도 작업 폴더에서 여러 Claude Code를 실행하여 개발 작업 배정, 진행 상황 확인, 중단된 세션 복구 지원, PR 완료 확인을 함께 관리합니다.

  • 여러 에이전트에 개발 작업 분담
  • 진행 상황과 빈 worktree 확인
  • 중단된 에이전트 재개
Significant-Gravitas/AutoGPT18.8만2026년 10월 23일 업데이트

perf-compare

무료요약 있음AI 평가 100점

Sentry 데이터로 변경 전후나 환경 간 속도와 실패율을 비교합니다. 통계적 변동을 고려해 빨라짐, 느려짐, 변화 감지 안 됨, 데이터 부족을 판정합니다.

  • 릴리스 전후 성능 비교
  • 미리 보기 환경과 대조 환경 검증
  • 다른 처리의 성능 저하 확인
Significant-Gravitas/AutoGPT18.8만2026년 10월 23일 업데이트

pr-address

무료요약 있음AI 평가 60점

PR 검토 의견을 모아 코드 수정, 커밋, 답변과 스레드 해결을 진행합니다. CI 실패, 충돌, 새 댓글도 계속 확인하며 대응이 끝날 때까지 추적합니다.

  • PR 검토에서 지적된 코드 수정
  • 사람과 봇의 검토 의견에 답변
  • 푸시 후 CI 실패 조사와 수정
Significant-Gravitas/AutoGPT18.8만2026년 10월 23일 업데이트

pr-polish

무료요약 있음AI 평가 70점

PR 검토와 수정을 반복하며 미해결 의견, CI 실패, 병합 충돌을 확인합니다. 늦게 도착하는 댓글도 기다려 PR을 병합할 수 있는 상태로 정리합니다.

  • PR을 병합 가능한 상태로 정리
  • 새 지적이 없어질 때까지 수정
  • 늦게 도착하는 봇 검토에 대응
Significant-Gravitas/AutoGPT18.8만2026년 10월 23일 업데이트

pr-review

무료요약 있음AI 평가 70점

코드 변경 제안인 PR의 목적과 차이를 읽고 정확성, 보안, 설계, 테스트를 점검합니다. 기존 의견과 중복되지 않도록 심각도를 붙여 해당 코드 줄에 댓글을 게시합니다.

  • 병합 전 PR 검토
  • 코드 변경의 보안 점검
  • 경계 조건의 테스트 누락 확인
Significant-Gravitas/AutoGPT18.8만2026년 10월 23일 업데이트

Significant-Gravitas의 스킬 모두 보기

이 스킬의 문제 신고