이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
테스트 코드를 처음 작성한 것은 인턴 프로젝트에서 기존 코드에 버그가 발생할 것 같아 수정이 두려웠던 순간이었습니다. 단위 테스트를 먼저 작성하고 리팩터링했더니 수정 후에도 기존 동작이 유지된다는 확신이 생겼고, 작업 속도가 오히려 빨라졌습니다.
pytest로 작성한 테스트 중 가장 유용했던 것은 경계 조건 케이스였습니다. 빈 배열, null 입력, 최대값 등을 명시적으로 테스트하니 정상 경로에서 보이지 않던 엣지 케이스가 발견됐습니다. 이런 케이스는 실제 운영에서 먼저 터지기 쉽습니다.
팀 내에서 테스트 커버리지를 올리자는 제안도 했습니다. 처음에는 시간이 걸린다는 반응이 있었지만, 한 번 버그를 테스트로 잡고 나서 팀원들도 테스트 작성을 자연스럽게 받아들였습니다.
테스트를 열심히 작성했는데 오히려 유지하기 어려워지는 경험을 했습니다. E2E 테스트를 많이 추가했더니 환경에 따라 테스트가 성공했다 실패했다 하는 플래키(flaky) 문제가 생겼습니다. 외부 API에 의존하는 테스트가 네트워크 상태에 따라 달라지는 것이었는데, 신뢰할 수 없는 테스트는 없는 것보다 오히려 나쁘다는 것을 이때 배웠습니다. 모킹도 너무 많이 쓰면 실제 동작과 다른 것을 테스트하게 된다는 함정을 경험했습니다. DB를 목으로 교체했더니 테스트는 다 통과했는데 실제 DB에서 쿼리가 실패하는 버그가 있었습니다. 이후 단위 테스트에서는 순수 함수 위주로 테스트하고, DB 연동은 테스트 DB를 직접 쓰는 통합 테스트로 검증하는 방식으로 구조를 바꿨습니다.
테스트는 많을수록 좋은 것이 아니라 신뢰할 수 있는 테스트가 적당히 있는 것이 더 좋다는 것을 이 경험에서 배웠습니다.
단위 테스트는 잘 작성했는데 두 모듈을 합치고 나서 버그가 나는 경험을 했습니다. 각 함수를 개별적으로 테스트하면 다 통과하는데, 실제로 연결하니 데이터 형식이 맞지 않아서 오류가 생기는 경우였습니다. 이 경험이 통합 테스트의 필요성을 직접 체감하게 한 계기였습니다. API 엔드포인트 레벨에서 요청을 보내고 응답을 검증하는 통합 테스트를 추가했는데, 단위 테스트가 놓친 모듈 간 계약 오류를 잡을 수 있었습니다. 테스트 작성 순서도 이때 바꿨습니다. 구현을 다 만들고 나중에 테스트를 추가하면 테스트가 구현의 형태를 따라가는데, 테스트를 먼저 작성하면 함수의 인터페이스를 먼저 설계하게 되는 효과가 있었습니다. 완벽하게 TDD를 적용하지는 못했지만, 중요한 로직은 먼저 테스트 케이스를 정의하고 구현하는 방식이 설계에 도움이 된다는 것을 배웠습니다.
통합 테스트는 단위 테스트가 못 잡는 모듈 간 경계 오류를 커버한다는 것을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.