인프런 커뮤니티 질문&답변

백엔드해야지님 안녕하세요. 우선 강의 수강해주셔서 감사드립니다!

말씀하신 부분의 제 의도를 정확히 이해하신 것으로 생각됩니다. 🙂

1번에 대해서 조금 부가 설명을 드려보면, A 클래스에 코드가 늘어나서 일부 코드를 B 클래스로 분리하면 어떤 분들은 B 클래스에 대한 인터페이스를 만들어서 B 클래스를 주입하도록 하기도 합니다. 그러면 B 클래스는 A 클래스의 변형된 구현 설계임에도 public으로 노출되고 A 클래스의 관계가 복잡해 집니다.

안녕하세요, 인프런 AI 인턴입니다.
백엔드해야지 님의 질문에 답변드리겠습니다.

과도한 테스트 격리에 대한 문제점, 특히 ‘부적절한 설계 왜곡’의 예시는 백엔드해야지 님께서 관찰하신 상황과 잘 맞아 보입니다. 아래 각각의 상황을 좀 더 설명드리겠습니다:

1. new 연산자로 직접 만들어도 좋은 클래스 인스턴스를 굳이 주입 & 클래스 의존을 인터페이스 의존으로 변경:

   • 테스트 환경에서 의존성을 주입받아 mock으로 대체하려는 경우를 들 수 있습니다. 특정 의존성이 단순한 구현체나 직접 생성 가능한 경우에도, 테스트의 독립성을 위해 과도하게 주입받아 사용하는 사례를 얘기하시는 것 같습니다. 이는 테스트 격리를 위한 설계이지만, 실제 코드를 복잡하게 만들고 불필요한 추상화를 유발할 수 있습니다.
     

2. private을 public으로 변경:

   • 주로 테스트의 목적을 위해 접근 제한자를 변경하는 경우가 이에 해당합니다. 특정 메서드가 클래스 내부에서만 사용되지만, 이 메서드를 테스트하기 위해 public으로 변경한다면 이는 코드의 캡슐화를 무너뜨릴 수 있습니다. 이로 인해 테스트를 위해 코드의 자연스런 설계를 왜곡할 위험이 있습니다.
     

이러한 예시는 테스트를 위해 본래 설계 의도와 달리 코드의 구조나 접근성을 변화시킬 때 생길 수 있는 문제입니다. 본 강의에서 언급된 내용과 일치하는 것 같습니다. 강의를 잘 청취하고 계신 것 같아 기쁩니다. 추가 질문이 있으시다면 언제든지 문의해 주세요!

참고 자료: “Spring Boot Reference Documentation - Testing”