TDD를 수행하면서 모든 메소드를 테스트 해야 한다는 생각을 가지고 있었다. 테스트 코드를 작성하다 보니 “private으로 선언된 메소드들은 어떻게 테스트를 해야하지?” 라는 질문이 생겼다. 이에 대한 해결책으로 reflection을 사용하여 private 메소드를 테스트코드를 작성했다.

이를 보고, 멘토님께서 질문해 주셨다.

<aside> 💡 Q : “private 메소드 테스트 코드를 작성하셨네요? 왜 private 메소드 테스트를 작성했나요?” A : “…”

</aside>

생각해보니, reflection에 대해서 찾다가 private 메소드를 테스트 하는 방식은 지양해야 한다는 글을 보았던 것 같다. 그래서, 조금 더 찾아 보기로 했다.

private 메소드를 사용하는 이유

먼저, 우리가 private 메소드를 사용하는 이유에 대해서 알아보자.

• private 메소드를 사용함으로써 내부 상세 로직을 외부로부터 숨기고 접근을 제한함으로써 캡슐화를 구현할 수 있다.
• 세부 로직을 숨김으로써 클래스 인터페이스를 단순화 하고, 외부 코드와의 결합도를 낮춤으로써 유지보수성을 높일 수 있다.

여기에 private 메소드 테스트를 지양해야 하는 이유가 담겨있다.

private 메소드 테스트를 지양해야 하는 이유

• 외부로부터 은닉한 세부 로직을 테스트에 꺼내 쓰게 된다면 캡슐화가 깨지게 된다.
• private 메소드는 public 메소드에 의해 호출된다. 잘 짜여진 코드라면 public 메소드를 통해 간접적으로 테스트가 가능해야 한다.
• private 메소드가 변경 될 때마다 테스트 코드를 다시 작성해야 한다. 이는 유지보수성을 떨어뜨린다.

그래서 private 메소드는 테스트하지 마?

Should I test private methods or only public ones?

위 링크는 private 메소드 단위 테스트에 대한 다양한 의견들을 볼 수 있다. 각자의 주장은 대강 이렇다.(서로 논쟁하는 모습을 보면 3자의 입장에서는 꽤나 흥미롭다.)