이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
테스트 가능한 코드를 위해 가장 먼저 신경 쓰는 건 의존성이 코드 안에 박혀 있지 않은 것입니다. 특정 외부 서비스나 데이터베이스를 코드 내부에서 직접 생성하면, 테스트할 때 그것 없이는 코드가 실행이 안 됩니다. 학부 프로젝트에서 클래스 내부에서 직접 DB 연결을 생성하는 코드를 작성했는데, 테스트를 짜려고 보니 DB 없이는 아무것도 실행이 안 됐습니다. 그때 의존성을 외부에서 주입하는 방식으로 바꾸고 나서야 테스트에서 목(mock) 객체를 쓸 수 있게 됐습니다. 처음엔 구조가 복잡해 보였는데, 실제로 테스트를 짜기 시작하니까 코드의 역할 분리가 훨씬 명확해진다는 걸 느꼈습니다. 테스트 가능한 코드가 곧 좋은 구조의 코드라는 걸 이 경험으로 이해했습니다. 아직 실무 수준과는 차이가 있지만, 이 방향을 계속 발전시키고 싶습니다.
테스트 가능한 코드를 쓰기 위해 함수나 메서드 단위를 작게 유지하는 것을 가장 먼저 합니다. 한 함수가 너무 많은 일을 하면 어느 부분을 테스트해야 하는지 불명확해집니다. 학부 프로젝트에서 입력 검증 + 데이터 가공 + 저장을 한 함수에서 처리하는 코드를 작성했다가, 테스트 하나가 실패했을 때 어디서 실패한 건지 파악하기가 너무 어려웠습니다. 그 이후로 각 역할을 분리하고, 각각 독립적으로 테스트하는 방식으로 바꿨습니다. 테스트를 짤 때는 경계 케이스를 먼저 생각합니다. 빈 값, 최대/최소값, 예상치 못한 타입 등을 의도적으로 넣어봤을 때 코드가 어떻게 반응하는지 확인합니다. 한 번은 문자열이 들어올 줄 몰랐던 숫자 처리 함수에서 예외 없이 통과됐다가 런타임 에러가 난 적이 있었고, 그 이후로 타입 체크 테스트를 추가했습니다.
테스트 주도 개발 방식을 한 번 직접 시도해봤습니다. 기능을 짜기 전에 테스트를 먼저 쓰고, 그 테스트가 통과되도록 코드를 만드는 흐름입니다. 처음엔 테스트를 먼저 쓰는 게 어색했습니다. 코드가 없는데 어떻게 테스트를 쓰냐는 느낌이었습니다. 익숙해지니까 테스트를 먼저 쓰는 것이 기능 요구사항을 정리하는 과정이기도 하다는 걸 알게 됐습니다. 무엇을 만들어야 하는지가 더 명확해지는 효과가 있었습니다. 실패한 부분도 있습니다.
처음 짠 테스트가 너무 구체적이어서, 구현 방식을 조금만 바꿔도 테스트가 깨졌습니다. 테스트는 동작을 검증해야지 구현을 검증하면 안 된다는 피드백을 받고 나서 방식을 수정했습니다. 아직 완전히 익숙하지 않지만, 테스트를 먼저 생각하는 습관이 코드 품질을 높인다는 방향은 맞다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.