Testing private method - Methods Should Be Public?

발생일: 2009.12.08

문제:
xper 그룹스 메일링을 받아보고 있는데,
오늘 누군가가 TDD(Test Driven Development) 진행 중 생긴 문제점에 대해 질문을 한 내용이 있다.

유닛 테스트를 위해 모든 메서드를 public 으로 선언하다보니,
"public 메서드가 너무 남발되는 게 아닌가, 객체지향의 원칙을 깨버리는 게 아닌가." 하는 생각이 들었다고 한다.

나도 예전에 같은 문제로 질문한 적이 있었는데,
그 당시에 멤버 변수는 private 으로, 메서드는 모두 public 으로 설정하는 쪽으로 결론을 냈었다.

그에 따라 (테스트를 위해) private 으로 작성된 메서드의 접근자를 단순히 모두 public 으로 바꾸는 식으로 구현했었다.
이 때는 마틴파울러의 Refactoring 책을 읽고 있어서 Replace Temp With Query 기법을 쓴답시고
마침 private 메서드가 굉장히 많을 때이기도 했다.
(결국 한 클래스에 잘게 쪼개진 public 메서드가 꽤 많이 생기게 됐다.)

헌데 요새 디자인 패턴에 대해 공부하다 보니,
요 놈들을 클래스로 빼내고 프록시 패턴이나 퍼사드 패턴을 써서 정리할 수도 있을 것 같다.


여튼, 그건 그렇고, 나도 아직 궁금하다.
과연 단지 유닛 테스트를 하기 위해서 모든 메서드를 public 으로 선언해야 할까?

해결책:
이에 대한 토론이 활발하게 있었다고 한다.

일단 토론은 'private 메서드를 어떻게 테스트 할 것인가? (Testing Private Interfaces)' 부터 시작됐겠다.

그러다 모든 메서드는 public 이어야 한다. 라는 주장이 나오게 된 듯 하다.

Methods Should Be Public (영문)

"모든 메서드를 Public 으로 하자"는 토론에 대해 정리해보면 아래와 같다.
(각자의 의견을 주거니 받거니 하고 있어 재밌다.^^)

* 다홍색은 찬성하는 측의 주장,
- 보라색은 반대하는 측의 주장이다.

    [테스팅]
    * 테스트 하기 용이하다. More public Methods == more testing
   
    - 테스트 이외에 무슨 이점이 있는가?
       
   
    [재사용성]
    * private 한 메서드가 많을 경우 재사용성이 떨어진다.
      서브클래스 등에서 재사용에 대한 기회가 떨어진다.
   
    * 이미 작성된 private 코드 중, 다른 그룹에서 재사용 될 만한 것들이 많이 존재할 수 있다.
     
    - 모든 메서드를 public 으로 할 경우, 커플링이 발생할 확률이 높아져 오히려 재사용성이 떨어진다.
     
    - 재사용에 대한 기대(Opportunistic reuse)는 좋은 생각이 아니다.
      코드의 재사용은 목적으로 가지고 해야지, 우연에 의해 사용되어선 안된다.
     
       
    [private 메서드]
    * private 코드는 클래스 내에서 자기 자리를 찾지 못한 메서드라고 할 수 있으므로, 리팩토링이 필요하다.
      (Extract Class 등으로 리팩토링 해야 한다.)
     
    - 한 메서드에서 내부적으로 여러 개의 복잡한 일이 일어날 경우,
      리팩토링(Extract Method 또는 Replace Temp With Query)를 통해 메서드를 간소화할 수 있으며
      나눠진 메서드를 private 으로 유지할 수 있다.
   
    - 유저에게 단순히 addUser() 메서드만 보여줄 수 있는데,
      중간에 데이터베이스 핸들링 코드와 같은 low level 코드를 다 보여줄 것인가?
       
    * 한 클래스 안의 모든 메서드를 public 으로 만든다는 게
      private 메서드까지 다 포함하여 public으로 만든다는 이야기가 아니다.
      private 한 메서드는 utility class 나 또는 다른 클래스로 분리되어야 한다는 이야기다.
      (리팩토링이 필요하다는 이야기다)
   
    - 접근에 대한 인터페이스를 간소화하고 명확하게 할 수 있다.
      (프레임웍을 개발한다고 생각해보라)
     
    * 프록시 패턴(또는 퍼사드 패턴 등)을 통해 인터페이스를 명확하게 할 수 있다. 
   
       
    [접근 제한]
    - 접근 제한(scoping)은 객체 지향에서 중요하며 유용하게 사용된다. (캡슐화 관점에서)
     
    - 허용되지 않은 유저가 객체의 private 한 정보를 사용할 수 있지 않은가?
   
    * 훌륭한 객체 지향 프로그램인 Smalltalk 에는 private 이란 접근 제한자 자체가 없으며,
      (모든 메서드가 public 이다)
      많은 금융 시스템에서 안전하게 잘 구축되어 작동하고 있다.
   
       
    [문서화 및 커멘트]
    - 문서화 툴(예: JavaDoc)을 사용할 경우, 유용하게 사용할 수 있다.
   
    * 개발자가 문서를 오픈하는 경우가 얼마나 있다고 생각하는가?
      대부분 코드를 직접 보거나, 테스트 코드를 확인한다.
      오히려 잘 작동하는 테스트 코드를 작성하는 것이 낫다.
   
    * 꼭 필요할 경우, 커멘트(주석) /* {private} */ 를 통해 메서드의 유효 범위를 알려 줄 수 있다.
   
    - 컴파일러가 이미 알고 있는 방법이 있는데, 왜 굳이 커멘트를 달아서 표현하는가?
   
    - 그룹 내에서 개발할 경우 메서드의 의도가 분명하게 전달될 지 몰라도,
      외부에 배포할 경우 잘 모르는 사용자가 코드를 잘못 사용할 수 있다.

어느 쪽의 의견이 맞다고는 할 수 없겠다.^^;

나는 개인적으로 private 메서드를 쓰는 걸 좋아하긴 하지만,
이 참에 한 번 모든 메서드를 public 으로 쓰는 쪽으로 시도해보려고 한다.

단순히 private 제한자를 public 으로 replace 하는 것 말고,
디자인 자체를 변경하면서 말이다.


그렇다면 어떻게 적용해야 할까....?
위 토론 중에도 있던 내용인데, 참고가 될 것 같아 내용을 덧붙여 적어본다.

한 클래스에 public 메서드와 private 메서드가 있다.
public 메서드는 object 를 조작하는 용도로 쓰이고,
private 메서드는 object 의 내부적인 작업을 하는데 쓰인다.

모두 public으로 구현해야 한다면,
public interface 를 가진 객체를 만들고, 그 안에 내부적인 작업을 할 멤버 객체를 만들어야 한다는 건가?
유저는 public interface를 가진 객체를 호출하고 말이다.

기존에 아래와 같은 코드가 있다면.

    class Foo {
        public int compute() {
            return computeA() + computeB();
        }
      
        private int computeA() {
            ...
            return result;
        }
      
        private int computeB() {
            ...
            return result;
        }
    }
   

아래와 같이 리팩토링 하면 되겠다. (모두 테스팅이 가능하다.)

   
    class Foo {
        private Bar bar;
      
        public int compute() {
            return bar.computeA() + bar.computeB();
        }
    }   
   
    class Bar {
        public int computeA() {
            ...
            return result;
        }
      
        public int computeB() {
            ...
            return result;
        }
    }