이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 각자 단위 테스트를 쓰는 방식이 달랐고, 어떤 파일엔 테스트가 있고 어떤 파일엔 없었습니다. 머지할 때 테스트가 깨지는 빈도가 늘어나면서 팀 내에서 테스트 구조를 정리하자는 이야기가 나왔습니다.
저는 테스트 파일 위치, 네이밍 규칙, Mock 사용 기준을 한 페이지로 정리해 팀에 공유했습니다. 픽스처 데이터도 공용 폴더로 모으고, 팀원이 새 테스트를 추가할 때 기존 예시를 참고할 수 있게 했습니다.
처음엔 규칙이 너무 많다는 피드백이 있었고, 절반을 삭제하고 가장 충돌이 잦은 3가지만 규칙으로 남겼습니다. 이후 PR에서 테스트 관련 코멘트가 눈에 띄게 줄었습니다. 규칙은 적을수록 지켜진다는 걸 그때 배웠습니다.
인턴 때 단위 테스트는 있었지만 DB와 연동한 통합 테스트가 없어서 배포 후 예상 못한 SQL 오류가 종종 생겼습니다. 통합 테스트 환경을 붙이는 작업을 맡았습니다.
테스트마다 임시 DB를 띄우고 종료 후 자동 정리하는 방식을 써봤습니다. 처음엔 테스트 실행 시간이 너무 길어서 팀원들이 로컬에서 잘 안 돌렸습니다. 테스트 속도가 느리면 안 돌리게 된다는 걸 실감했습니다.
병렬 실행 설정을 추가하고, 무거운 테스트는 CI에서만 돌리도록 분리했습니다. 로컬 기준 전체 테스트가 3분에서 45초로 줄었고 이후로 팀원들이 커밋 전 테스트를 자연스럽게 돌리게 됐습니다. 테스트 인프라는 속도가 채택률을 결정한다는 것이 그때의 교훈입니다.
사이드 프로젝트에서 회원가입부터 주문까지 전체 흐름을 자동화 테스트로 커버하겠다는 목표로 브라우저 기반 테스트를 도입했습니다. 처음엔 잘 돌아갔지만 UI가 조금만 바뀌어도 테스트가 깨졌고, 한 달 후엔 테스트 코드를 고치는 시간이 기능 개발보다 길어졌습니다.
결국 팀에서 핵심 사용자 흐름 3개만 남기고 나머지는 단위 테스트로 대체하기로 결정했습니다. 제가 제안했던 방향이 틀렸다는 걸 인정하고 롤백하는 과정이 쉽지 않았지만, 결과적으로 팀 속도가 회복됐습니다.
넓은 커버리지가 항상 좋은 건 아니다는 걸 배웠습니다. 유지할 수 있는 범위의 테스트가 포기되는 넓은 테스트보다 낫습니다. 지금은 테스트 전략을 짤 때 커버리지보다 유지 비용을 먼저 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성물산 건설부문 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.