2025-08-27
1일 1아티클
데보션
통합 테스트 환경 구축
문제 상황
- 외부 Model Provider와의 연동
- Provider 서버 직접 연동하여 테스트 → 오류 발생 시 원인 파악 어려움 (코드가 문제인지, 서버가 문제인지?), 버전 업데이트로 인한 스펙 변경, etc.
- 서버 내 Mock API 제작하여 테스트 → API 변경 사항 발생 시 Mock API도 함께 변경하는 번거로움 발생
WireMock
- API mock testing 오픈소스 도구
- F.I.R.S.T Unit Test 가능
WireMock,Docker,GitLab CI사용
- 외부 API를 Mock하면서 독립적으로 테스트 가능한 환경 생성, 자동화된 파이프라인 안에 적용
아키텍처 수정
- 기존 : 외부 서버를 직접 연동하여 에러 응답 테스트 난해, DB와 Redis를 직접 로컬에서 실행하여 번거로움
- 수정 : 외부 서버 대신
WireMock사용하고, DB와 Redis까지 모두 Docker 환경으로 실행하여 GitLab CI 환경에서도 통합 테스트 수행 가능
성과
- 테스트에 대한 신뢰 증가
- 로컬에서도 간편한 MSA 환경 테스트 가능
- 생산성 향상
- 필요한 응답 패턴만 정의하면 WireMock이 서버처럼 자동으로 응답하기 때문에, 테스트 시나리오 작성의 불필요한 비용 최소화
단순 테스트 환경 구성 경험이 아닌, 팀 전체의 개발 사이클을 바꾼 경험
새로운 API Provider, 요구사항 등이 발생해도 해당 환경을 확장 (확장성)
F.I.R.S.T 원칙 |
|
|---|---|
| 1. Fast | 일반적으로 작성한 테스트 케이스는 빨라야 한다. |
| 2. Independent | 각각의 테스트 케이스는 독립적이어야 한다. |
| 3. Repeatable | 테스트 케이스는 어떤 환경에서도 반복 실행이 가능해야 한다. |
| 4. Self-validating | 단위 테스트는 성공/실패라는 자체 검증 결과를 보여주어야 한다. |
| 5. Timely | 단위 테스트는 테스트할 기능 구현을 하기 직전에 작성해야 한다. |
이전에 한 프로젝트에서 TDD 환경을 구성하고 단위 테스트부터 통합 테스트까지 직접 테스트 코드를 작성했던 기억이 있다. 당시 API 개발에 소요된 시간보다 테스트 코드 작성에 소요된 시간이 더 많았고, 이게 효율적인 개발 사이클이 맞는지 의문이 들었다. 다음 프로젝트에서는 이런 고민을 해결할 수 있는 WireMock을 사용해 보면 좋겠다는 생각이 든다.
오늘 배운 것
- 알고리즘
- swea 2382 미생물 격리
- 시뮬레이션
내일 할 일
- 상담 피드백 바탕으로 포트폴리오 수정 (다음주 주말까지는 완료)