객체지향 시니어 테스트·코드품질 면접

먼저 현재 시스템의 동작을 스냅샷으로 캡처하는 Golden Master Testing을 적용하여 입출력 쌍을 기록합니다. 다음으로 Characterization Test를 작성해 현재 코드의 실제 동작(버그 포함)을 문서화하고, 이를 기반으로 안전망을 구축합니다. Seam을 식별하여 의존성을 분리할 수 있는 지점을 찾고, 해당 부분부터 단위 테스트를 추가합니다. 비즈니스 크리티컬한 경로부터 우선순위를 두어 테스트를 작성하고, Strangler Fig 패턴으로 새 코드를 점진적으로 도입합니다. 리팩토링 후에는 Golden Master와 비교하여 동작 변경이 없음을 검증하고, 점진적으로 더 세밀한 단위 테스트로 교체해 나갑니다.

SRP 검증을 위해 '이 클래스가 변경되어야 하는 이유가 여러 개인가?', '클래스 이름이 And, Or, Manager를 포함하는가?'를 질문합니다. OCP는 '새로운 기능 추가 시 기존 코드 수정이 필요한가?', '조건문 대신 다형성을 사용할 수 있는가?'로 확인합니다. LSP는 '하위 타입이 상위 타입의 계약을 위반하는가?', 'instanceof나 타입 체크가 과도하게 사용되는가?'를 점검합니다. ISP는 '인터페이스 구현체가 사용하지 않는 메서드를 구현하는가?'를, DIP는 '고수준 모듈이 저수준 구현에 직접 의존하는가?'를 확인합니다. 또한 Long Method, Feature Envy, Data Clumps 같은 코드 냄새 패턴을 체크리스트에 포함하고, 테스트 가능성과 Mock 의존도를 평가하여 설계 품질을 판단합니다.

Contract Testing은 서비스 간 인터페이스 계약을 검증하는 것으로, Consumer가 기대하는 계약을 정의하고 Provider가 이를 준수하는지 독립적으로 확인합니다. E2E 테스트는 전체 시스템을 실제로 구동하여 통합 동작을 검증하지만, 환경 구성 비용이 크고 실행 속도가 느립니다. CDC 전략으로는 먼저 Consumer 팀이 Pact 파일로 기대 계약을 정의하고, 이를 Pact Broker에 공유합니다. Provider는 CI/CD 파이프라인에서 Consumer의 계약을 검증하는 테스트를 실행하여, 배포 전에 호환성을 보장합니다. 버전별 계약을 관리하고, Can-I-Deploy 도구로 배포 가능 여부를 사전 검증합니다. E2E 테스트는 핵심 비즈니스 시나리오만 선별하여 최소화하고, 대부분의 통합 검증은 빠르고 안정적인 Contract Testing으로 대체합니다.

TDD는 테스트를 먼저 작성함으로써 클라이언트 관점에서 API를 설계하게 하여, 사용하기 쉬운 인터페이스를 만들도록 유도합니다. 테스트 가능한 코드를 작성하려면 의존성을 주입 가능하게 만들어야 하므로, 자연스럽게 DIP를 따르고 결합도가 낮아집니다. 예를 들어, 테스트에서 Mock 객체를 주입하려다 보면 구체 클래스 대신 인터페이스에 의존하게 되고, 이는 OCP와 LSP 준수로 이어집니다. Red 단계에서 실패하는 테스트를 작성하면 요구사항이 명확해지고, Green 단계에서 최소 구현으로 빠르게 피드백을 받으며, Refactor 단계에서 안전하게 설계를 개선할 수 있습니다. 초기 투자 시간은 있지만, 디버깅 시간 감소, 리팩토링 안정성, 회귀 버그 방지로 장기적 생산성이 향상됩니다.

Stub은 미리 정의된 응답을 반환하여 간접 입력을 제어하고, Mock은 호출 여부와 순서 등 상호작용을 검증합니다. Spy는 실제 객체를 래핑하여 일부 동작만 감시하고, Fake는 실제 동작하는 경량 구현체입니다. 과도한 Mock 사용은 구현 세부사항에 의존하게 만들어 리팩토링 시 테스트가 깨지기 쉽고, 실제 통합 문제를 놓칠 수 있습니다. Value Object나 Entity는 실제 객체를 사용하고, 외부 시스템이나 느린 I/O는 Stub이나 Fake를 사용합니다. 협력 객체 간 상호작용이 중요한 경우에만 Mock을 사용하며, Repository는 In-Memory Fake를 만들어 실제 동작을 검증하는 것이 좋습니다. Mock 사용은 최소화하고, 행위 검증보다 상태 검증을 우선하며, 테스트가 구현이 아닌 인터페이스에 의존하도록 설계합니다.