api-tester

API Tester

프론트엔드 ↔ 백엔드 API 연동을 실제로 검증하는 테스트 스킬.

사용법

"로그인 API 테스트해줘"
"프론트-백엔드 연동 검증해줘"
"/api-tester"

---

워크플로우

1. 환경 감지

서버 실행 상태 확인:

# 백엔드 포트 확인
curl -s http://localhost:8000/health || curl -s http://localhost:3001/health

# 프론트엔드 포트 확인
curl -s http://localhost:3000 || curl -s http://localhost:5173

프록시 설정 확인 (vite.config.ts, next.config.js, package.json proxy 등):

# Vite 프록시
grep -r "proxy" vite.config.* 2>/dev/null

# Next.js rewrites
grep -r "rewrites\|destination" next.config.* 2>/dev/null

# CRA proxy
grep "proxy" package.json 2>/dev/null

2. CORS 검증

# preflight OPTIONS 요청
curl -v -X OPTIONS http://localhost:8000/api/users \
  -H "Origin: http://localhost:3000" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: Content-Type,Authorization" \
  2>&1 | grep -i "access-control"

기대 결과:

• Access-Control-Allow-Origin: 프론트엔드 origin 포함
• Access-Control-Allow-Methods: 필요한 HTTP 메서드 포함
• Access-Control-Allow-Headers: Content-Type, Authorization 포함
• Access-Control-Allow-Credentials: true (쿠키 사용 시)

3. 인증 흐름 검증

# 로그인 → 토큰 발급
TOKEN=$(curl -s -X POST http://localhost:8000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"test1234"}' \
  | jq -r '.token // .access_token // .accessToken')

echo "Token: ${TOKEN:0:20}..."

# 보호된 API 호출
curl -s http://localhost:8000/api/users/me \
  -H "Authorization: Bearer $TOKEN" | jq .

# 만료/잘못된 토큰
curl -s -w "\nHTTP Status: %{http_code}\n" \
  http://localhost:8000/api/users/me \
  -H "Authorization: Bearer invalid-token"

기대 결과:

• 올바른 토큰: 200 + 사용자 정보
• 잘못된 토큰: 401 Unauthorized
• 토큰 없음: 401 또는 403

3-1. API 직접 호출·서버 검증 (관련 API 필수)

상세 기준은 skills/code-reviewer/references/security-audit.md의 API 직접 호출·서버 검증 계약이다. 프로젝트에 없으면 현재 CLI 활성 루트, 이어서 SKILLS-CATALOG.md의 code-reviewer 원본 경로로 해석하고 그 모듈의 참조를 직접 읽는다. source-only를 slash 호출하거나 전역 활성화하지 않는다. 참조 누락은 NOT RUN으로 남긴다. 대상 API에 계약 ID별 사례를 매핑하고 기존 QA의 누락을 보충한다. UI 입력만으로 끝내지 않고 독립 계정의 직접 HTTP 요청(기존 API 테스트 또는 Playwright request)을 실행한다. 정상 대조군·거부 응답·저장/상태/부수 효과의 전후 비교와 실행 증거를 계약 형식으로 남긴다. 기존 증거는 대상 버전·환경·조건이 같을 때 재사용한다. 서버·계정·관찰 수단 부족은 NOT RUN이며, 필수 사례 미실행을 전체 PASS로 표시하지 않는다. 명시적 UI-only 범위에서는 API 시험을 확장하지 않고 API 보안 검증 제외를 보고한다. 테스트를 통과시키려고 검증을 제거하거나 거부 기대값을 완화하지 않는다.