TIL - 20260727

juni·2026년 7월 27일

목록 보기

415/468

0727 프론트엔드 실무 심화 (9/N): 테스트, QA와 배포 전 검증 기준

✅ 1. 프론트엔드 테스트란 무엇인가?

프론트엔드 테스트는 화면이 의도한 대로 보이고, 사용자가 원하는 행동을 했을 때 기능이 정상 동작하는지 확인하는 작업입니다.
단순히 “버튼이 보인다”를 확인하는 것이 아니라, 검색, 필터, 폼 제출, 권한 버튼 노출, 로딩/에러/빈 상태, 모바일 UX까지 확인해야 합니다.
고객 화면에서는 전환 실패를 막고, 관리자 화면에서는 운영 실수를 줄이는 것이 핵심입니다.

화면 렌더링 확인
  ↓
사용자 입력 확인
  ↓
API 상태별 UI 확인
  ↓
권한별 UI 확인
  ↓
모바일/반응형 확인
  ↓
배포 전 회귀 테스트

➕ 1-1. 프론트엔드 테스트가 중요한 이유

고객이 상담 신청을 못 하는 문제를 배포 전에 막을 수 있습니다.
관리자 페이지에서 상태 변경, 엑셀 다운로드, 검색 필터가 깨지는 것을 줄일 수 있습니다.
리팩토링 후 기존 화면이 망가졌는지 확인할 수 있습니다.
AI가 수정한 코드가 의도하지 않은 UI 변경을 만들었는지 점검할 수 있습니다.
운영자가 “갑자기 안 돼요”라고 말하기 전에 개발자가 먼저 잡을 수 있습니다.

테스트 없이 배포:
상담 신청 버튼 클릭 안 됨
검색 필터 URL 반영 안 됨
상태 변경 후 목록 갱신 안 됨
모바일 모달 잘림
VIEWER에게 수정 버튼 노출

프론트엔드 장애는 서버 장애처럼 로그에 바로 드러나지 않을 때가 많습니다.
그래서 배포 전 체크리스트와 수동 QA가 특히 중요합니다.

✅ 2. 테스트와 QA의 차이

테스트는 특정 기능이 기대한 결과를 내는지 확인하는 작업입니다.
QA는 실제 사용 흐름 기준으로 화면 전체를 검증하는 작업입니다.
자동 테스트가 있어도 수동 QA는 필요합니다.

구분	설명	예시
단위 테스트	작은 함수/컴포넌트 검증	상태 배지 라벨
컴포넌트 테스트	UI 컴포넌트 동작 검증	폼 검증, 버튼 노출
E2E 테스트	실제 사용자 흐름 검증	로그인 → 상담 검색 → 상태 변경
수동 QA	사람이 직접 화면 확인	모바일 상담 신청, 관리자 필터

➕ 2-1. 실무 기준

자동 테스트:
반복 가능하고 깨지면 바로 알아야 하는 핵심 로직

수동 QA:
디자인, 반응형, 모달, 실제 사용감, 배포 전 최종 확인

모든 것을 자동화하려고 하면 시간이 너무 많이 듭니다.
1인 개발자는 핵심 로직은 자동화하고, 실제 화면 흐름은 체크리스트로 관리하는 방식이 현실적입니다.

✅ 3. 프론트엔드 테스트 종류

➕ 3-1. 단위 테스트

함수, 유틸, 상태 매핑 같은 작은 단위를 테스트합니다.

전화번호 정규화
금액 포맷팅
날짜 포맷팅
상태값 라벨 매핑
권한 체크 함수
URL query 파싱 함수

➕ 3-2. 컴포넌트 테스트

특정 컴포넌트가 props나 사용자 입력에 따라 올바르게 렌더링되는지 확인합니다.

Button loading 상태
FormField error 표시
ConsultStatusBadge 라벨
EmptyState action 버튼
권한별 RowAction 버튼 노출
상담 신청 폼 유효성 검증

➕ 3-3. E2E 테스트

실제 브라우저에서 사용자 흐름 전체를 검증합니다.

고객 상담 신청
관리자 로그인
상담 목록 검색
상담 상태 변경
상품 등록/수정
엑셀 다운로드 요청

E2E는 강력하지만 작성/유지 비용이 큽니다.
정말 중요한 흐름부터 적용하는 것이 좋습니다.

✅ 4. 1인 개발자 기준 테스트 우선순위

모든 화면을 완벽히 테스트하려고 하면 오래 못 갑니다.
장애가 나면 매출/운영에 큰 영향을 주는 곳부터 테스트해야 합니다.

➕ 4-1. 최우선 테스트 대상

고객 상담 신청 폼
사전예약 신청 폼
상품 상세 CTA
관리자 로그인
관리자 상담 목록 검색/필터
상담 상태 변경
권한별 버튼 노출
엑셀 다운로드 요청

➕ 4-2. 두 번째 우선순위

상품 목록/상세 렌더링
배너 노출
FAQ/리뷰 표시
상품 등록/수정 폼
배너 등록/수정 폼
알림 재발송 버튼
ExportJob 목록

➕ 4-3. 낮은 우선순위

정적 안내 페이지
단순 문구 영역
거의 변경되지 않는 footer
디자인만 있는 보조 섹션

테스트는 “중요도 × 변경 빈도 × 장애 영향도” 기준으로 잡는 것이 좋습니다.

✅ 5. 테스트 도구 선택

React 프로젝트에서는 보통 Vitest, React Testing Library, Playwright 조합을 많이 씁니다.

도구	용도
Vitest	단위 테스트, 빠른 실행
React Testing Library	컴포넌트 테스트
Playwright	E2E 브라우저 테스트
MSW	API mocking
Storybook	컴포넌트 상태 확인/문서화

➕ 5-1. 현실적인 조합

초기:
Vitest + React Testing Library

API mocking 필요:
MSW 추가

핵심 사용자 흐름:
Playwright 추가

공통 UI 많아짐:
Storybook 검토

처음부터 모든 도구를 도입할 필요는 없습니다.
작은 유틸 테스트와 핵심 컴포넌트 테스트부터 시작하는 것이 좋습니다.

✅ 6. Vitest 기본

Vitest는 Vite 기반 프로젝트에서 쓰기 좋은 테스트 러너입니다.
빠르고 TypeScript와 궁합이 좋습니다.

➕ 6-1. 설치 예시

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

➕ 6-2. package.json 스크립트

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

➕ 6-3. 설정 예시

import { defineConfig } from 'vite';

export default defineConfig({
  test: {
    environment: 'jsdom',
    setupFiles: './src/test/setup.ts',
  },
});

➕ 6-4. setup.ts

import '@testing-library/jest-dom';

jsdom은 브라우저 DOM 환경을 흉내 내기 위해 사용합니다.
React 컴포넌트 테스트에는 거의 필요합니다.

✅ 7. 유틸 함수 테스트

유틸 함수는 테스트하기 쉽고 효과가 좋습니다.
전화번호, 금액, 날짜, 권한 체크 같은 로직은 실수하면 여러 화면에 영향을 줍니다.

➕ 7-1. 전화번호 정규화 함수

export function normalizePhone(value: string) {
  return value.replace(/\D/g, '');
}

➕ 7-2. 테스트 코드

import { describe, expect, it } from 'vitest';
import { normalizePhone } from './normalizePhone';

describe('normalizePhone', () => {
  it('하이픈을 제거한다', () => {
    expect(normalizePhone('010-1234-5678')).toBe('01012345678');
  });

  it('공백과 문자를 제거한다', () => {
    expect(normalizePhone('010 1234 abcd')).toBe('0101234');
  });
});

➕ 7-3. 테스트하면 좋은 유틸

normalizePhone()
formatPhone()
formatCurrency()
formatDateTime()
parsePage()
parseLimit()
hasPermission()
getErrorMessage()
getStatusLabel()

이런 테스트는 작성 비용이 낮고, 리팩토링할 때 큰 도움이 됩니다.

✅ 8. 상태 Badge 테스트

상태값 라벨과 색상 매핑은 관리자 테이블에서 자주 쓰입니다.
상태가 잘못 표시되면 운영자가 잘못 판단할 수 있습니다.

➕ 8-1. 컴포넌트 예시

const CONSULT_STATUS_LABEL = {
  PENDING: '대기',
  CALLING: '상담중',
  DONE: '완료',
  CANCELLED: '취소',
} as const;

function ConsultStatusBadge({ status }: { status: keyof typeof CONSULT_STATUS_LABEL }) {
  return <span>{CONSULT_STATUS_LABEL[status]}</span>;
}

➕ 8-2. 테스트 예시

import { render, screen } from '@testing-library/react';
import { describe, expect, it } from 'vitest';
import { ConsultStatusBadge } from './ConsultStatusBadge';

describe('ConsultStatusBadge', () => {
  it('PENDING 상태를 대기로 표시한다', () => {
    render(<ConsultStatusBadge status="PENDING" />);

    expect(screen.getByText('대기')).toBeInTheDocument();
  });

  it('DONE 상태를 완료로 표시한다', () => {
    render(<ConsultStatusBadge status="DONE" />);

    expect(screen.getByText('완료')).toBeInTheDocument();
  });
});

단순해 보여도 상태 매핑 테스트는 실무에서 의미가 있습니다.
enum이 추가되거나 변경될 때 빠르게 확인할 수 있습니다.

✅ 9. 권한 기반 UI 테스트

관리자 화면에서 권한별 버튼 노출은 반드시 확인해야 합니다.
VIEWER에게 상태 변경, 삭제, 엑셀 다운로드 버튼이 보이면 안 됩니다.

➕ 9-1. 테스트 대상

VIEWER는 상태 변경 버튼을 볼 수 없음
ADMIN은 상태 변경 버튼을 볼 수 있음
MARKETER는 엑셀 다운로드 버튼을 볼 수 없음
SUPER_ADMIN은 관리자 관리 메뉴를 볼 수 있음

➕ 9-2. 예시

import { render, screen } from '@testing-library/react';
import { describe, expect, it } from 'vitest';
import { ConsultRowActions } from './ConsultRowActions';

describe('ConsultRowActions', () => {
  it('VIEWER에게 상태 변경 버튼을 보여주지 않는다', () => {
    render(
      <ConsultRowActions
        permissions={['CONSULT_READ']}
        consultId={1}
      />,
    );

    expect(screen.queryByText('상태 변경')).not.toBeInTheDocument();
  });

  it('CONSULT_UPDATE 권한이 있으면 상태 변경 버튼을 보여준다', () => {
    render(
      <ConsultRowActions
        permissions={['CONSULT_READ', 'CONSULT_UPDATE']}
        consultId={1}
      />,
    );

    expect(screen.getByText('상태 변경')).toBeInTheDocument();
  });
});

프론트 권한 테스트는 UX 확인용입니다.
실제 보안은 백엔드 권한 테스트도 함께 있어야 합니다.

✅ 10. 폼 유효성 테스트

상담 신청, 사전예약 신청, 상품 등록 폼은 테스트 가치가 높습니다.
입력값이 잘못됐을 때 에러 메시지가 표시되는지 확인해야 합니다.

➕ 10-1. 테스트 대상

이름 필수
전화번호 필수
전화번호 형식
상품 선택 필수
중복 신청 서버 에러 표시
제출 중 버튼 disabled
성공 후 완료 메시지

➕ 10-2. React Testing Library 기본 방향

폼 렌더링
  ↓
사용자 입력
  ↓
제출 버튼 클릭
  ↓
에러 메시지 확인
  ↓
API 호출 여부 확인

➕ 10-3. 예시 흐름

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { describe, expect, it } from 'vitest';
import { ConsultForm } from './ConsultForm';

describe('ConsultForm', () => {
  it('전화번호가 비어 있으면 에러를 표시한다', async () => {
    const user = userEvent.setup();

    render(<ConsultForm productId={1} />);

    await user.click(screen.getByRole('button', { name: '상담 신청' }));

    expect(
      await screen.findByText('전화번호를 입력해 주세요.'),
    ).toBeInTheDocument();
  });
});

테스트에서는 실제 사용자가 보는 텍스트와 역할 기준으로 찾는 것이 좋습니다.
getByRole, getByLabelText, getByText를 적극 활용합니다.

✅ 11. API Mocking과 MSW

컴포넌트 테스트에서 실제 API를 호출하면 테스트가 불안정해집니다.
MSW(Mock Service Worker)를 사용하면 API 응답을 테스트에서 가짜로 만들 수 있습니다.

➕ 11-1. MSW가 필요한 이유

서버 없이 프론트 테스트 가능
성공/실패/빈 상태를 쉽게 재현
네트워크 에러 테스트 가능
API 응답 형태를 고정해 테스트 안정화

➕ 11-2. Mock 시나리오

상담 목록 성공
상담 목록 빈 결과
상담 목록 500 에러
상담 신청 성공
상담 신청 중복 에러
로그인 만료 401
권한 없음 403

로딩/에러/빈 상태를 제대로 테스트하려면 Mock이 필요합니다.
백엔드가 준비되지 않았을 때도 프론트 UI 개발을 진행할 수 있습니다.

✅ 12. 로딩/에러/빈 상태 테스트

0720에서 다룬 화면 상태는 테스트에서도 중요합니다.
API 상태별로 올바른 UI가 나오는지 확인해야 합니다.

➕ 12-1. 테스트 대상

최초 로딩 시 Skeleton 표시
성공 시 테이블 표시
데이터 없음 시 EmptyState 표시
API 실패 시 ErrorState 표시
ErrorState에서 다시 시도 버튼 표시
권한 없음 403 시 Forbidden 안내

➕ 12-2. 예시 문장

상담 목록 API가 빈 items를 반환하면
"조건에 맞는 상담 신청이 없습니다" 문구가 보여야 한다.

상담 목록 API가 500을 반환하면
"상담 목록을 불러오지 못했습니다" 문구와 다시 시도 버튼이 보여야 한다.

Empty와 Error는 반드시 구분해서 테스트해야 합니다.
빈 데이터는 정상 응답이고, 에러는 실패 응답입니다.

✅ 13. URL 상태 테스트

관리자 검색/필터/페이지네이션은 URL 상태와 연결되어야 합니다.
이 부분은 버그가 자주 생깁니다.

➕ 13-1. 테스트 대상

검색 버튼 클릭 시 keyword가 URL에 반영됨
상태 필터 변경 시 status가 URL에 반영됨
필터 변경 시 page가 1로 초기화됨
페이지 이동 시 page만 변경됨
필터 초기화 시 기본 URL로 돌아감
잘못된 page 값은 1로 보정됨

➕ 13-2. QA 예시

1. 상담 목록에서 keyword=아이폰 검색
2. URL에 keyword=아이폰 확인
3. 새로고침
4. 검색어와 결과 유지 확인
5. page=2 이동
6. 뒤로가기
7. page=1 또는 이전 조건 복구 확인

URL 상태는 자동 테스트도 좋지만, 수동 QA로 반드시 확인해야 합니다.
실제 브라우저의 뒤로가기/새로고침 동작이 중요하기 때문입니다.

✅ 14. Playwright E2E 테스트

Playwright는 실제 브라우저에서 사용자 흐름을 테스트하는 도구입니다.
핵심 흐름만 자동화해도 배포 안정성이 크게 올라갑니다.

➕ 14-1. 설치 예시

npm install -D @playwright/test
npx playwright install

➕ 14-2. 테스트 후보

고객 상담 신청 성공
상담 신청 중복 에러 표시
관리자 로그인 성공
상담 목록 검색
상담 상태 변경
권한 없는 메뉴 미노출
상품 등록/수정

➕ 14-3. 예시 흐름

import { expect, test } from '@playwright/test';

test('고객이 상담 신청을 완료할 수 있다', async ({ page }) => {
  await page.goto('/products/1');

  await page.getByRole('button', { name: '상담 신청' }).click();

  await page.getByLabel('이름').fill('홍길동');
  await page.getByLabel('전화번호').fill('01012345678');

  await page.getByRole('button', { name: '상담 신청' }).click();

  await expect(page.getByText('상담 신청이 완료되었습니다.')).toBeVisible();
});

E2E 테스트는 사용자 관점에서 작성하는 것이 좋습니다.
CSS class보다 role, label, text 기준으로 찾는 것이 더 안정적입니다.

✅ 15. E2E 테스트 도입 시 주의점

E2E 테스트는 강력하지만 비용이 있습니다.
테스트 데이터, 로그인 계정, API 상태, DB 초기화 기준을 정해야 합니다.

➕ 15-1. 주의할 점

테스트 데이터가 매번 달라지면 실패 가능
운영 서버 대상으로 테스트 금지
테스트 계정 권한 필요
외부 알림톡/SMS 실제 발송 방지
결제/주문/상담 실제 데이터 생성 주의

➕ 15-2. 추천 환경

로컬:
개발 중 빠른 확인

스테이징:
배포 전 핵심 흐름 검증

운영:
읽기 전용 smoke test만 조심스럽게

실제 고객에게 알림이 가거나 운영 DB에 테스트 데이터가 들어가면 안 됩니다.
E2E는 테스트 환경부터 정리해야 합니다.

✅ 16. 수동 QA 체크리스트의 중요성

1인 개발자에게 가장 현실적인 것은 자동 테스트 + 수동 QA 체크리스트 조합입니다.
모든 걸 자동화하지 못해도 체크리스트가 있으면 배포 전 실수를 크게 줄일 수 있습니다.

➕ 16-1. 수동 QA가 필요한 영역

모바일 화면 깨짐
모달 위치/스크롤
이미지 비율
버튼 터치 영역
실제 브라우저 뒤로가기
권한별 메뉴 확인
디자인 가독성
고객 안내 문구

이런 것들은 자동 테스트만으로 잡기 어렵습니다.
특히 모바일 상담 신청 흐름은 실제 기기에서 눌러보는 것이 좋습니다.

✅ 17. 고객 화면 QA 체크리스트

➕ 17-1. 상품 목록

상품 목록이 정상 노출되는가?
상품 이미지가 깨지지 않는가?
상품명, 가격, 혜택 정보가 잘 보이는가?
카테고리/검색/필터가 정상 동작하는가?
로딩/빈 상태/에러 상태가 자연스러운가?
모바일에서 카드가 깨지지 않는가?

➕ 17-2. 상품 상세

대표 이미지가 정상 노출되는가?
상품명, 출고가, 지원금, 월 예상 요금이 잘 보이는가?
혜택 안내가 모바일에서 읽히는가?
리뷰/FAQ가 정상 표시되는가?
Sticky CTA가 콘텐츠를 가리지 않는가?
상담 신청 버튼이 명확히 보이는가?

➕ 17-3. 상담 신청

모달이 정상으로 열리는가?
이름/전화번호 입력이 가능한가?
전화번호 입력 시 숫자 키패드가 뜨는가?
필수값 누락 시 에러가 표시되는가?
제출 중 버튼이 비활성화되는가?
성공 시 완료 메시지가 표시되는가?
실패 시 이해 가능한 에러 메시지가 표시되는가?
모바일에서 모달이 화면 밖으로 잘리지 않는가?

✅ 18. 관리자 화면 QA 체크리스트

➕ 18-1. 로그인/권한

관리자 로그인이 정상 동작하는가?
로그인 만료 시 로그인 페이지로 이동하는가?
권한 없는 메뉴가 숨겨지는가?
권한 없는 URL 직접 접근 시 ForbiddenPage가 보이는가?
VIEWER에게 수정/삭제/엑셀 버튼이 보이지 않는가?
403 API 응답이 권한 없음 메시지로 표시되는가?

➕ 18-2. 상담 목록

상담 목록이 정상 조회되는가?
검색어 입력 후 URL에 반영되는가?
상태/유입경로/날짜 필터가 정상 동작하는가?
필터 변경 시 page가 1로 초기화되는가?
새로고침 후 검색 조건이 유지되는가?
Empty 상태에서 필터 초기화 버튼이 보이는가?
API 실패 시 다시 시도 버튼이 보이는가?
모바일에서 핵심 정보가 확인되는가?

➕ 18-3. 상태 변경

상태 변경 모달이 정상으로 열리는가?
변경 가능한 상태만 선택 가능한가?
상태 변경 사유 입력이 필요한 경우 검증되는가?
제출 중 버튼이 비활성화되는가?
성공 후 목록이 갱신되는가?
실패 시 에러 메시지가 표시되는가?
권한 없는 사용자는 상태 변경할 수 없는가?
완료/취소 상태에서 잘못된 변경이 막히는가?

➕ 18-4. 엑셀 다운로드

현재 검색 조건 기준으로 다운로드 요청되는가?
권한 없는 사용자는 버튼이 보이지 않는가?
다운로드 전 Confirm이 표시되는가?
개인정보 포함 안내가 있는가?
요청 성공 후 안내 메시지가 표시되는가?
ExportJob 목록에서 상태를 확인할 수 있는가?
실패 시 재시도 또는 안내가 있는가?

✅ 19. 반응형/접근성 QA 체크리스트

➕ 19-1. 반응형

모바일, 태블릿, PC에서 주요 화면이 깨지지 않는가?
상담 신청 버튼이 모바일에서 잘 보이는가?
모달이 모바일에서 화면 밖으로 벗어나지 않는가?
테이블이 작은 화면에서 사용 가능한가?
이미지 비율이 깨지지 않는가?
배너 텍스트가 모바일에서 읽히는가?
Sticky CTA가 하단 콘텐츠를 가리지 않는가?
관리자 사이드바가 모바일에서 Drawer로 잘 동작하는가?

➕ 19-2. 접근성

버튼은 button, 링크는 a를 사용하는가?
input에 label이 연결되어 있는가?
에러 메시지가 input과 연결되어 있는가?
Tab 이동 순서가 자연스러운가?
포커스 스타일이 보이는가?
모달에서 포커스가 배경으로 빠지지 않는가?
ESC 또는 닫기 버튼으로 모달을 닫을 수 있는가?
색상만으로 상태를 전달하지 않는가?

✅ 20. 배포 전 프론트엔드 검증 명령어

배포 전에는 최소한 lint, test, build를 확인해야 합니다.

➕ 20-1. 기본 명령어

npm run lint
npm run test:run
npm run build

➕ 20-2. 타입 체크가 따로 있는 경우

npm run typecheck

➕ 20-3. Playwright가 있는 경우

npx playwright test

1인 개발자라도 npm run build는 반드시 배포 전에 돌리는 것이 좋습니다.
타입 에러나 번들 오류는 배포 전에 잡아야 합니다.

✅ 21. 배포 전 git diff QA

AI IDE나 Codex가 여러 파일을 수정했다면 git diff 확인은 필수입니다.
프론트엔드는 의도치 않은 CSS 변경, 공통 컴포넌트 변경, 라우팅 변경이 화면 전체에 영향을 줄 수 있습니다.

➕ 21-1. 확인할 것

공통 Button/Input/Modal 변경 여부
권한 체크 로직 변경 여부
API client/interceptor 변경 여부
queryKey 변경 여부
라우팅 변경 여부
CSS 전역 스타일 변경 여부
환경변수 추가 여부
삭제된 파일 여부

➕ 21-2. AI에게 diff 리뷰 요청

아래 git diff를 프론트엔드 배포 전 QA 관점으로 리뷰해줘.

중점:
1. 공통 컴포넌트 변경으로 다른 화면에 영향이 있는지
2. 권한 기반 UI가 깨질 가능성이 있는지
3. queryKey/invalidate 로직이 잘못된 곳이 있는지
4. 상담 신청/관리자 검색/상태 변경 흐름에 영향이 있는지
5. 모바일 레이아웃이 깨질 수 있는 CSS 변경이 있는지
6. 환경변수나 API URL 변경이 있는지
7. 배포 전 반드시 수동 QA해야 할 화면

답변은 위험도 높은 순서로 정리해줘.

diff 리뷰는 “뭘 테스트해야 하는지”를 정하는 데 매우 유용합니다.

✅ 22. 프론트엔드 Smoke Test

Smoke Test는 배포 후 서비스가 기본적으로 살아 있는지 빠르게 확인하는 테스트입니다.
깊은 QA가 아니라, 핵심 기능이 깨지지 않았는지 확인하는 최소 검증입니다.

➕ 22-1. 고객 화면 Smoke Test

메인 페이지 접속
상품 목록 접속
상품 상세 접속
상담 신청 모달 열기
필수값 검증 확인
테스트 신청 가능 여부 확인

➕ 22-2. 관리자 화면 Smoke Test

관리자 로그인
상담 목록 조회
검색/필터 1회 실행
상담 상세 열기
상태 변경 모달 열기
엑셀 다운로드 버튼 권한 확인

➕ 22-3. 주의할 점

운영에서 실제 상담 신청 데이터 생성 주의
테스트 데이터 표시/삭제 기준 필요
알림톡/SMS 실제 발송 방지
주문/결제 같은 실제 영향 작업 주의

운영 Smoke Test는 실제 고객 데이터에 영향을 주지 않게 설계해야 합니다.
가능하면 스테이징 환경에서 전체 QA를 하고, 운영은 읽기 중심으로 확인하는 것이 좋습니다.

✅ 23. 회귀 테스트

회귀 테스트(Regression Test)는 새로 수정한 기능 때문에 기존 기능이 깨지지 않았는지 확인하는 테스트입니다.
프론트엔드에서는 공통 컴포넌트와 상태 관리 변경 후 회귀 문제가 자주 생깁니다.

➕ 23-1. 회귀 테스트가 필요한 변경

Button/Input/Modal 공통 컴포넌트 수정
API client 수정
Auth/Permission 로직 수정
TanStack Query 설정 수정
라우팅 구조 변경
전역 CSS 변경
상담 신청 폼 수정
관리자 테이블 공통화

➕ 23-2. 예시

Button 컴포넌트에 loading 처리 추가
  ↓
상담 신청 버튼 정상?
  ↓
상태 변경 버튼 정상?
  ↓
엑셀 다운로드 버튼 정상?
  ↓
삭제 confirm 버튼 정상?

공통 컴포넌트를 수정할 때는 해당 컴포넌트를 쓰는 주요 화면을 같이 확인해야 합니다.

✅ 24. 테스트 데이터 관리

테스트를 제대로 하려면 테스트 데이터가 필요합니다.
운영 데이터로 테스트하면 위험합니다.

➕ 24-1. 필요한 테스트 데이터

상담 신청 대기/상담중/완료/취소
상품 노출/비노출
배너 활성/비활성
권한별 관리자 계정
알림 성공/실패 이력
ExportJob 대기/진행/완료/실패
검색 결과 없음 조건

➕ 24-2. 권한 테스트 계정

SUPER_ADMIN 테스트 계정
ADMIN 테스트 계정
MANAGER 테스트 계정
MARKETER 테스트 계정
VIEWER 테스트 계정

권한별 테스트 계정이 없으면 권한 UI를 제대로 검증하기 어렵습니다.
최소한 VIEWER와 ADMIN 정도는 확인할 수 있어야 합니다.

✅ 25. 테스트 자동화 도입 순서

지금 당장 모든 테스트를 자동화할 필요는 없습니다.
실무에서는 가장 위험한 기능부터 작게 시작하는 것이 좋습니다.

➕ 25-1. 1단계: 유틸 테스트

전화번호 정규화
금액 포맷
날짜 포맷
권한 체크
URL query 파싱
상태 라벨 매핑

➕ 25-2. 2단계: 핵심 컴포넌트 테스트

상담 신청 폼
권한별 버튼 노출
상태 Badge
Empty/ErrorState
검색 폼

➕ 25-3. 3단계: 핵심 E2E

고객 상담 신청
관리자 로그인
상담 검색
상태 변경
권한 없는 메뉴 미노출

➕ 25-4. 4단계: CI 연결

PR/Push 시 lint
test:run
build
핵심 E2E
실패 시 배포 중단

1인 개발자는 1단계와 2단계만 해도 효과가 큽니다.
E2E는 정말 중요한 흐름부터 천천히 추가하면 됩니다.

✅ 26. 실무 체크리스트

➕ 26-1. 자동 테스트 체크리스트

유틸 함수 테스트가 있는가?
상태 라벨/배지 테스트가 있는가?
권한 기반 버튼 노출 테스트가 있는가?
상담 신청 폼 검증 테스트가 있는가?
Empty/ErrorState 테스트가 있는가?
URL query 파싱 테스트가 있는가?
핵심 E2E 후보가 정리되어 있는가?
테스트가 실제 사용자 관점으로 작성되어 있는가?

➕ 26-2. 수동 QA 체크리스트

고객 상담 신청 흐름을 실제로 눌러봤는가?
관리자 로그인/상담 목록/검색/상태 변경을 확인했는가?
권한별 메뉴와 버튼 노출을 확인했는가?
모바일에서 상품 상세와 상담 신청 모달을 확인했는가?
로딩/에러/빈 상태를 확인했는가?
새로고침/뒤로가기/URL 공유를 확인했는가?
공통 컴포넌트 변경 영향 범위를 확인했는가?
배포 후 Smoke Test 항목이 정리되어 있는가?

➕ 26-3. 배포 전 체크리스트

npm run lint 통과
npm run test:run 통과
npm run build 통과
환경변수 변경 여부 확인
API 응답 구조 변경 여부 확인
공통 컴포넌트 변경 여부 확인
권한 로직 변경 여부 확인
모바일 핵심 화면 확인
릴리즈 노트 작성
롤백 기준 확인

✅ 27. AI를 활용해 프론트엔드 테스트/QA를 설계할 때 질문법

AI에게 테스트를 설계시킬 때는 화면 종류, 핵심 사용자 흐름, 사용하는 라이브러리, API 상태, 권한 조건을 구체적으로 알려줘야 합니다.

➕ 27-1. 좋은 질문 예시

React + TanStack Query + react-hook-form 기반 온라인 휴대폰 판매몰 프론트엔드 테스트/QA 전략을 세우고 싶어.

상황:
1. 고객 화면에는 상품 목록, 상품 상세, 상담 신청 모달이 있음
2. 관리자 화면에는 로그인, 상담 목록, 검색/필터, 상태 변경, 엑셀 다운로드가 있음
3. 폼은 react-hook-form + zod를 사용함
4. 서버 상태는 TanStack Query로 관리함
5. 권한은 ADMIN, MANAGER, VIEWER가 있고 VIEWER는 수정/엑셀 불가
6. 검색 조건은 URL query string에 남김
7. 모바일 상담 신청 UX가 중요함
8. 1인 개발자라 모든 테스트를 한 번에 자동화하기는 어려움

요청:
- 테스트 우선순위
- Vitest/React Testing Library 테스트 후보
- Playwright E2E 후보
- 수동 QA 체크리스트
- 권한별 UI 테스트 기준
- 로딩/에러/빈 상태 테스트 기준
- 배포 전 검증 명령어
- 단계별 도입 순서
를 실무 기준으로 정리해줘.

➕ 27-2. AI 답변 검증 기준

모든 테스트를 한 번에 자동화하라고 하지 않는가?
고객 상담 신청과 관리자 핵심 흐름을 우선순위에 두는가?
권한별 UI 테스트를 포함하는가?
URL 상태와 뒤로가기/새로고침 QA를 포함하는가?
모바일 상담 신청 UX를 확인하라고 하는가?
lint/test/build 배포 전 검증을 포함하는가?
E2E 테스트의 테스트 데이터 위험을 언급하는가?
1인 개발자 기준의 현실적인 도입 순서를 제안하는가?

📌 요약

프론트엔드 테스트는 화면이 의도대로 보이고, 사용자의 입력과 행동에 맞게 기능이 정상 동작하는지 확인하는 작업입니다.
1인 개발자는 모든 테스트를 완벽히 자동화하기보다, 핵심 유틸/컴포넌트 테스트와 수동 QA 체크리스트를 조합하는 것이 현실적입니다.
고객 화면에서는 상품 상세, 상담 신청 모달, 모바일 CTA, 폼 검증이 중요하고, 관리자 화면에서는 로그인, 검색/필터, 상태 변경, 권한 버튼, 엑셀 다운로드가 중요합니다.
Vitest는 유틸/단위 테스트, React Testing Library는 컴포넌트 테스트, Playwright는 핵심 사용자 흐름 E2E 테스트에 적합합니다.
권한 기반 UI는 VIEWER에게 수정/삭제/엑셀 버튼이 보이지 않는지, ADMIN에게 필요한 버튼이 보이는지 테스트해야 합니다.
Empty 상태와 Error 상태는 반드시 구분해서 확인해야 하며, API 실패 시 재시도 버튼과 적절한 메시지가 필요합니다.
검색 조건은 URL query string에 남아야 하므로 새로고침, 뒤로가기, 필터 초기화, page 초기화까지 QA해야 합니다.
배포 전에는 최소한 npm run lint, npm run test:run, npm run build를 확인하고, 공통 컴포넌트/권한/API client 변경 여부를 diff로 점검해야 합니다.
E2E 테스트는 강력하지만 테스트 데이터와 환경 관리가 필요하므로, 운영 DB나 실제 알림톡/SMS에 영향을 주지 않게 조심해야 합니다.
테스트의 목적은 “코드를 많이 검사하는 것”이 아니라, 실제 고객과 운영자에게 중요한 흐름이 배포 후 깨지지 않게 막는 것입니다.

juni

이전 포스트

TIL - 20260725

다음 포스트