ttipo
7897f2de20
템플릿 점검에서 나온 항목을 한 번에 반영한다. 항목별 이유: - Node 20 → 24 LTS (Dockerfile·CI): Node 20 은 2026-04-30 에 지원이 끝나 보안 패치가 없다 - backend·frontend .dockerignore 추가: `COPY . .` 가 호스트 node_modules(Windows 바이너리)·dist· .env*(시크릿)를 이미지에 넣고 있었다 - 업로드 디렉터리 쓰기 검사(fail-fast): Linux 에서 Docker 가 root 소유로 만든 바인드 마운트에 비-root 앱이 쓰지 못해 첫 업로드에서야 SYS_001 로 터졌다. 기동 시 해결 명령을 안내한다 - DB 커넥션 풀 100 → 10 (DB_POOL_MAX): PostgreSQL 기본 max_connections(100)를 앱 하나가 다 잡았다 - Swagger 운영 기본 비활성 (SWAGGER_ENABLED): API 구조 전체가 공개 도메인에 노출됐다 - 헬스체크 운영 응답에서 오류 상세 제거: 드라이버 오류 문구에 내부 주소·DB 계정명이 담긴다. 원인은 error 로그로 남긴다 - nginx: location 의 add_header 때문에 정적 자원에서 보안 헤더가 빠지던 문제와, index.html 이 캐시돼 배포 직후 빈 화면이 날 수 있던 문제를 고친다 - vite allowedHosts: true 제거 (DEV_ALLOWED_HOSTS): DNS rebinding 보호가 꺼져 있었다 - 전역 설정을 configureApp() 으로 분리해 main.ts 와 e2e 가 공유: e2e 가 설정을 복사해 재현해 실제 설정과 어긋나도 통과할 수 있었다. PORT 도 빈 값을 방어하는 파서를 거친다 - 쓰이지 않던 WEBSOCKET_PORT 제거: 별도 포트는 같은 도메인 라우팅과 맞지 않는다 - 예제 useUser 가 메시지 대신 에러 코드를 보관하도록 수정, testing.md 표 깨짐 수정, settings.json 허용 목록에서 npm install 제거 (Windows lock 파일 규칙과 충돌) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.1 KiB
4.1 KiB
name, description
| name | description |
|---|---|
| testing | 세 스택 공통 테스트 규칙 — 테스트 위치/네이밍, 무엇을 테스트할지, 커밋 전 실행. backend Jest, frontend Vitest, flutter flutter_test 기준. |
테스트 규칙
템플릿은 각 스택에 테스트 러너가 준비되어 있다 — backend
jest, frontendvitest, flutterflutter_test. 새 로직을 추가하면 최소한의 테스트를 함께 작성한다.
공통 원칙
- 무엇을 테스트하나: 순수 함수(utils), 서비스/비즈니스 로직, 에러 코드 매핑 분기를 우선한다. 프레임워크 기본 동작은 테스트하지 않는다.
- 공유 계약은 반드시 테스트한다 — 아래 "계약 테스트" 절 참조.
- 테스트는 결정적(deterministic) 으로 — 외부 네트워크/시간/랜덤에 의존하지 않도록 모킹한다.
- 커밋 전 실행 — 변경 영역의 테스트가 통과해야 한다. (checklist)
- CI 가 강제한다 —
.github/workflows/ci.yml이 세 스택의 lint·test·build 와 에러 코드 동기화를 PR 마다 검사한다. - 테스트 설명(it/test 제목)은 한국어로 "무엇을 검증하는지" 명확히 작성한다.
스택별 위치·실행
| 스택 | 러너 | 위치·네이밍 | 실행 |
|---|---|---|---|
| backend | Jest | 단위 *.spec.ts (소스 옆), e2e test/*.e2e-spec.ts |
npm run test, npm run test:e2e |
| frontend | Vitest | *.spec.ts / *.test.ts (대상 옆 또는 __tests__/) |
npm run test:unit |
| flutter | flutter_test | test/ 하위, *_test.dart |
flutter test |
예시 (backend 순수 유틸)
// shared/utils/format.spec.ts
import { formatSomething } from './format';
describe('formatSomething', () => {
it('빈 입력이면 빈 문자열을 반환한다', () => {
expect(formatSomething('')).toBe('');
});
});
계약 테스트 (삭제·비활성화 금지)
세 플랫폼이 공유하는 계약은 어긋나도 컴파일 에러가 나지 않는다. 아래 테스트가 그 안전망이다.
| 대상 | 위치 | 검증 내용 |
|---|---|---|
| 에러 코드 레지스트리 | backend/src/common/errors/error-codes.spec.ts |
네이밍 규약, 상태 역매핑, 클라이언트 전용 코드가 서버에서 선택되지 않음 |
| 에러 응답 포맷 | backend/src/common/filters/http-exception.filter.spec.ts |
코드/상태/traceId, 내부 정보 미노출, 검증 상세 사유 미노출 |
| 프론트 에러 사전 | frontend/src/composables/useApi.spec.ts |
코드 목록이 백엔드와 일치, 폴백 동작 |
| 앱 에러 사전 | flutter/test/error_lexicon_test.dart |
코드 목록이 백엔드와 일치, 폴백 동작 |
| 전역 설정 | backend/src/app.setup.spec.ts |
main.ts·e2e 가 공유하는 configureApp() 의 prefix·응답 래퍼·에러 필터·보안 헤더·CORS (DB 불필요) |
| 응답 계약 (e2e) | backend/test/app.e2e-spec.ts |
실제 HTTP 로 래퍼·에러코드·traceId·페이지네이션·헬스체크 형식 검증 |
e2e 는 main.ts 와 같은
configureApp()을 쓴다. 테스트에서 전역 설정을 따로 흉내 내지 않는다 — 흉내 낸 설정은 실제와 어긋나도 테스트가 통과해 버린다.
e2e 는 DB 가 필요하다 (AppModule 이 TypeORM 을 초기화한다). 로컬에서는 개발 스택을 띄운 뒤 컨테이너 안에서 실행하는 것이 가장 간단하다.
docker exec <프로젝트>-backend npx jest --config ./test/jest-e2e.jsonCI 는 postgres 서비스 컨테이너를 띄워 자동으로 실행한다.
- 에러 코드를 추가/삭제하면 세 곳의 기대 목록을 함께 갱신한다 (checklist 3절).
- 매핑 로직(응답 래퍼·상태 역매핑)을 바꾸면 해당 분기 테스트를 추가한다.
테스트하지 않아도 되는 것
- 프레임워크가 보장하는 동작 (라우팅, DI 주입 자체, ORM 쿼리 빌더)
- 단순 getter/setter, 위임만 하는 컨트롤러 메서드
- 화면 스타일·레이아웃 값
API 응답 래퍼/에러 코드는 세 플랫폼 공유 계약이다 (response-format · error-codes).