모듈 패턴에서의 테스트 (Testing at Javascript Module Pattern)

발생일: 2011.11.10

문제:
얼마 전 작은 애플리케이션을 하나 만들었는데,
애플리케이션을 구성하는 모듈의 대부분을 모듈 패턴(Module Pattern)으로 구현했었다.

모듈 패턴은 아래 예제와 같이 즉시실행함수와 클로저를 이용해 유효범위를 만들어,
private/public 개념을 흉내낸 패턴이다.

  var module = (function() {
    var private = 0; // private 멤버 (클로저 변수)

    function doPrivate() {
      private++;
    }

    // Public API
    return {
      doPublic: function() {
        doPrivate();
      }
    };
  }());
(좀 더 자세한 내용은 여기를 참조)

여튼, 개인적으로는 모듈 패턴을 사용하는 것을 꽤 선호했었다.
private 한 것과 public 한 것들을 확실하게 구별할 수 있고,
특히 모듈 내에서 (반복되고 번거롭다고 느꼈었던) this 키워드를 사용하지 않아도 되기 때문이었다.

하지만 한 가지 마음에 들지 않았던 점은,
private 메서드는 외부 접근이 불가능해 유닛 테스트하기가 어렵다는 것이다.

접근이 불가능하도록 하는 의도로 패턴을 사용하는 거라 당연한 것이기도 하고,
모듈을 작게 만들어서 공개 API만 테스트해도 되겠다만,..
음... 다른 사람들은 어찌 해결했나 궁금해서 좀 검색해봤다.


해결책:

모듈 패턴의 private 메서드 테스팅에 대한 내용은 아니지만,
비슷한 개념으로 답을 얻을 수 있는 포스트가 있었다.

조나단 스눅이란 아자씨가 2009년 4월에 모듈 패턴에 관해 포스팅을 한 게 있는데,
제목부터 막 끌린다.

    Why I don't love JavaScript's module pattern
    http://snook.ca/archives/javascript/no-love-for-module-pattern

조나단 아자씨가 모듈 패턴을 좋아하지 않는 이유를 가볍게 정리해보며 아래와 같다.

  - 디버깅이 불편하다.
        private 변수를 바로 볼 수 없으니까. 심지어 압축된 코드라고 생각해봐? 라며...

  - 확장이 쉽지 않다.

        마찬가지로 변수가 노출되어 있지 않기 때문에, 객체의 확장이 용이하지 않다.

  - AOP 적용이 어렵다.

        AOP 방식으로 구현한다 하더라도 숨겨진 속성들에 접근할 수 없기 때문에 효율적이지 않다.

  - private 한 변수는 접두사 언더바(_)를 사용하는 표기법 만으로도 충분하다.

댓글로 찬반에 대한 의견이 많은데, 그 중 니콜라스 자카스의 댓글이 모든 상황을 정리해주는 느낌이다.

자세하게 답변을 했는데 결국엔 "그 때 그 때 달라요~" 랄까.

그 외, 비슷한 주제에 대해,
'왜 private member가 필요하냐?'서부터 'javascript는 javascript 답게 써라'까지 여러 포스트가 있었는데.
역시 결론은 '상황에 맞게'인 것 같다. 테스팅도 마찬가지.


# 덧)
일전에 포스팅했던 Testing private method - Methods Should Be Public? 을 다시 읽어보니 재밌다.