Java 시니어 테스트 및 코드품질 기술면접

Testcontainers는 실제 환경과 동일한 컨테이너를 사용해 가장 높은 신뢰성을 제공하지만 테스트당 5-10초의 컨테이너 시작 시간이 소요되므로 @Container의 static 선언으로 테스트 클래스당 한 번만 시작하거나, Singleton Containers 패턴으로 전체 테스트 스위트에서 재사용해야 합니다. Embedded 서버(H2, Embedded Redis)는 빠르지만 실제 프로덕션 환경과 동작이 다를 수 있어 SQL 방언이나 특정 기능 차이로 인한 false positive가 발생할 수 있습니다. Mock/Stub은 가장 빠르지만 통합 지점의 실제 동작을 검증하지 못하므로 계약 테스트(Contract Testing)나 Consumer-Driven Contract를 함께 사용해야 합니다. CI 환경에서는 Testcontainers를 병렬 실행할 때 Docker 리소스 제한과 네트워크 격리를 위해 각 컨테이너에 랜덤 포트를 할당하고, 테스트 데이터는 UUID 기반 네임스페이스로 격리하며, @DirtiesContext나 트랜잭션 롤백으로 테스트 간 상태를 격리합니다. 실무에서는 빠른 피드백을 위한 Mock 기반 단위 테스트 70%, 핵심 시나리오 검증을 위한 Testcontainers 기반 통합 테스트 20%, E2E 테스트 10%의 테스트 피라미드 구조를 유지하는 것이 효과적입니다.

Mock은 메서드 호출 여부와 호출 횟수 등 행위를 검증하는 데 사용하고, Stub은 미리 정의된 응답을 반환해 상태 기반 테스트를 지원하며, Spy는 실제 객체를 부분적으로 모킹할 때 사용하고, Fake는 실제 구현의 경량 버전을 제공합니다. Mockito의 @Mock은 모든 메서드가 기본값(null, 0 등)을 반환하는 완전한 가짜 객체를 만들고, @Spy는 실제 객체를 감싸서 특정 메서드만 stubbing하고 나머지는 실제 로직이 실행되므로 레거시 코드 테스트나 부분 모킹이 필요할 때 유용합니다. Over-mocking을 방지하려면 public interface만 검증하고 내부 private 메서드 호출은 검증하지 않으며, verify() 사용을 최소화하고 상태 기반 검증을 우선하며, 테스트가 리팩토링에 취약하다면 Mock 대신 Fake 구현체를 만드는 것을 고려해야 합니다. WireMock은 HTTP 프로토콜 레벨에서 모킹하므로 실제 네트워크 호출 흐름을 검증할 수 있고 요청/응답 헤더, 상태 코드, 타임아웃 등을 정교하게 시뮬레이션할 수 있지만, RestTemplate을 직접 Mock하면 더 빠르고 간단하지만 HTTP 레이어의 실제 동작을 검증하지 못하므로 핵심 통합 테스트에는 WireMock을, 단순한 유닛 테스트에는 직접 Mock을 사용하는 것이 적절합니다.

TDD를 실천하려면 먼저 비즈니스 요구사항을 작은 단위로 분해하고, 가장 간단한 케이스부터 시작해 점진적으로 복잡도를 높여가며 테스트를 추가합니다. 외부 의존성이 있는 로직은 인터페이스로 추상화하고 Mock이나 Stub으로 대체해 단위 테스트를 작성하며, 실제 통합은 별도의 통합 테스트로 검증합니다. 레거시 코드에는 Characterization Test(현재 동작을 있는 그대로 기록하는 테스트)를 먼저 작성해 안전망을 구축한 후, Strangler Fig 패턴으로 새로운 기능은 TDD로 작성하고 점진적으로 레거시를 대체합니다. TDD는 테스트 가능한 설계를 강제하므로 낮은 결합도와 높은 응집도를 자연스럽게 유도하고, 테스트가 먼저 작성되므로 API 사용자 관점에서 인터페이스를 설계하게 되며, 리팩토링 단계에서 지속적으로 코드 품질을 개선할 수 있습니다. 하지만 TDD만으로는 아키텍처 레벨의 설계 문제를 해결할 수 없고, 테스트 작성 시간이 초기 개발 속도를 늦출 수 있으며, UI나 복잡한 알고리즘처럼 테스트 작성이 어려운 영역도 존재합니다.

Line Coverage는 실행된 코드 라인의 비율을 측정하고, Branch Coverage는 if/else 같은 분기문의 모든 경로를 실행했는지 측정하며, Path Coverage는 가능한 모든 실행 경로를 측정하지만 경로 수가 기하급수적으로 증가해 실무에서는 측정하기 어렵습니다. 높은 커버리지에도 품질이 낮은 이유는 테스트가 코드를 실행하기만 하고 결과를 검증(assertion)하지 않거나, 예외 상황이나 경계값을 테스트하지 않거나, 테스트가 의미 있는 비즈니스 시나리오를 검증하지 못하기 때문입니다. 커버리지 목표는 프로젝트 특성에 따라 다르지만 일반적으로 핵심 비즈니스 로직은 80% 이상, 전체 평균은 70% 이상을 권장하며, Getter/Setter나 단순 위임 메서드는 제외하고, UI 레이어보다 도메인 레이어에 더 높은 기준을 적용합니다. CI/CD에서는 커버리지 감소를 차단하는 것은 유용하지만 절대값 기준은 초기 레거시 프로젝트에서 진입 장벽이 되므로 점진적으로 목표를 높이고, 신규 코드에만 높은 기준을 적용하며, 커버리지와 함께 Mutation Testing(PIT)으로 테스트의 실제 품질을 검증하는 것이 효과적입니다.

God Class 리팩토링 전에는 먼저 Characterization Test로 현재 동작을 보호하는 테스트를 작성하고, 최소 70% 이상의 커버리지를 확보한 후 시작해야 하며, IDE의 자동 리팩토링 기능을 최대한 활용해 수동 실수를 방지합니다. Extract Method로 긴 메서드를 작은 단위로 나누고, Extract Class로 관련 메서드와 필드를 새로운 클래스로 분리하며, Move Method로 적절한 클래스로 책임을 이동시키는데, 각 단계마다 테스트를 실행해 회귀 버그를 즉시 발견합니다. 리팩토링 PR 검토 시에는 기능 변경이 없는지, 테스트가 모두 통과하는지, 순환 의존성이 생기지 않았는지, 새로운 클래스의 응집도가 높은지, 변경 범위가 적절한지를 확인하며, 리팩토링과 기능 개발이 섞인 PR은 반드시 분리를 요청해야 합니다. 리팩토링은 별도 PR로 먼저 머지하고 기능 개발은 그 위에 쌓는 것이 원칙이며, 부득이한 경우 커밋을 명확히 분리해 리뷰어가 구분할 수 있게 합니다. 마틴 파울러의 원칙 중 '리팩토링과 기능 추가를 분리하라'가 가장 중요한데, 두 가지를 동시에 하면 문제 발생 시 원인을 찾기 어렵고 코드리뷰가 복잡해지며 롤백도 어려워지기 때문입니다.