[TDD] 정독완료..TestCase의 private 메소드.

Posted at 2010.07.08 15:00 // in TDD // by MOOVA 무바㏇
테스트주도개발TDD실천법과도구
카테고리 컴퓨터/IT > 프로그래밍/언어 > JAVA > JAVA일반
지은이 채수원 (한빛미디어, 2010년)
상세보기
해당 포스트는 : http://moova.tistory.com/entry/SI에서-TDD에-대한-노력2 과 연결되어 있습니다.


나름대로 구입을 잘했다는 만족감.

목록중 대부분이 학습을 통해서 알게 되었거나 주시하는 RSS를 통해서 습득을 한 것들이어서 구입을 꺼려했는데, 막상 정독하고 보니 새롭게 알게된 사실도 몇 가지 있어서 대체적으로 만족할 만하다. 개인적으론 실무경험에 있어서 덧붙일 내용이 필요하다는 생각이 들었지만, 그것은 나중에 정리하기로 하고..

그리고, 내가 생각한 것과 똑같은 글귀를 보게 되어 좀 깜짝 놀랐다. 일을 하면서 이렇게 생각들이 일치한 사람을 만났다면 지금쯤 나는 어디서 무엇을 하고 있을가?

내가 생각했던 것과 같은 소견


책중 일부분 = private 메소드도 테스트 케이스를 만들어야 하나요?
우선 먼저 private 메소드가 왜 생기나? 혹은 언제 private메소드를 만들게 되나?를 생각해볼 필요가 있습니다.
java에서의 private은 접근 범위로 봤을 때 오직 자신의 클래스 내에서만 접근 가능한 속성이나 메소드입니다. 즉, 외부에 알리고 싶지 않은 부분이라는 전제하에 만들어집니다. 하지만 클래스의 효용 가치는 그 클래스가 갖고 있는 정보와 그 정보를 기반으로, 다른 클래스와 상호작용한다는 데 있습니다. 이를 모듈화, 독립화라고도 하는데, 다른 클래스 입장에서는 자신이 원하는 기능을 올바로 해주기만 하면 더 이상 신경 쓰지 않아도 되는 겁니다. 그리고 그 외부에 제공하는 기능이 제대로 동작하는지 보장해준다는 의미로 테스트케이스를 만드는거죠.. 생략...
public 메소드를 테스트하면 그에 딸린 private메소드는 자연스럽게 테스트되었다고 간주합니다.

KSUG에 올렸던 비슷한 내용
JUnit의 테스트 메소드는 왜 public이어야 할까요?

몇가지를 생각해 보았습니다.

먼저 의미상으로 '테스트'라는 것을 생각해보면..
테스트는 실제 돌아가는  모듈이나 단위 기능들을 점검하여 잘 돌아가는지 이리저리(?) 확인 하기 위한 것이라고 알고 있는데요

만약에 실제로 운용중인 기능들을 모두 테스트 한다고 치면,
구지 테스트를 숨길 필요가 있을까..하는 생각이 듭니다.
테스트 작성자가 테스트를 숨겨놓았다면 아마도 그것은 테스트를 기피하는 부분 이겠거나
아니면 양심 없는 코드를 작성해 놓았기 때문에 테스트를 숨겨놓았을 것입니다.

이렇게 의미상으로 보면 테스트는 모두에게 공개되어야 한다는 의미에서 language측면에서도 public이어야 한다는 생각을 하고 있구요.

두번째 접근은 리팩토링과 관련된 것입니다.
TDD방법에서는 테스트 코드를 먼저 만들고 실제  클래스를 생성해서 그안에 실제 메소드를 만들게 되죠.
대부분 클래스 안에 제일 처음 만들게 되는 메소드를 private으로 만들진 않는 것 같습니다..
처음부터 private으로 코드를 넣게 된다면 그분은 아마 대단한 실력가가 아닐까 생각합니다.

저는 대게 public으로 메소드를 만들고 필요에 따라서 extract method와 같은 리팩토링 기법을 사용해 중복되는 부분
이나 기능의 분할을 위해서 메소드를 private으로 빼는 습관이 있습니다.

리팩토링 된 private 메소드는 외부에서 직접 호출 하진 않죠(호출하는 방법도 있긴 하지만)
외부에서는 먼저 공개된 public메소드를 호출기준으로 삼고 클래스 내부에 있는 private메소드들는 자연스레 public
소드에서 사용 될테니까요. 만약에 클래스 내부에 private메소드가 심하게 있다고 치면 그 클래스는 단일책임원칙에 의해서 잘 설계된 클래스가 아니라고 생각됩니다. 이를테면 분할을 잘못한 구조이거나 procedure스타일로 짜여진 클래스일 가능성이 클 것 같습니다.

이렇듯 테스트는 테스트하기 편한 실제 코드를 좋아한다는 입장에서,
호출할 부분 즉, public메소드를 호출하는 입장에서 테스트 메소드가 private일 필요가 없다고 생각합니다.

이와 비교해서 테스트케이스 안에 메소드들이 public이어야 하는 점도 위와 비슷하게 생각을 해봅니다.
단위 테스트용 클래스들은 잘 분할된 실제 클래스를 테스트 하기 위한 메소드들이지
테스트 케이스안에 private 메소드들을 테스트하기 위한 것은 아닌 것 같습니다.
테스트케이스안에 private 메소드가 있다면 실제로 테스트안에서 리팩토링이 이루어졌다거나 아니면 중복되는 테스트를
private으로 뺐다는 가정이 있으므로, 이 관점에서 생각해 본다면 private 메소드는 테스트 대상이 될 수가 없는 것 같
습니다.

다음은 기술적인 관점입니다.
TestSuit류의 테스트를 하게 되면 한꺼번에 단위 테스트들를 묶어서 테스트하게 되겠죠. 이것도 위에서 설명한 것처럼 외부에
서 호출대상이 되는 부분은 공개 되어진 부분이지 숨어 있는 부분이 아니란 점입니다. 테스트가 숨어있다면 분명 공개된 테스트에서
이미 사용하고 있을 가능성이 크기 때문입니다.

생각나는대로 적으려다가.. 좀 더 생각하고 적었습니당;;;



결론은 내가 생각했던 것과 같은 이야기다.. 사뭇 놀람.. 세상엔 비슷한 생각을 하는 사람들이 의외로 많다. 좀처럼 찾아 볼 수 없다는게 흠이지만..
저작자 표시 비영리 변경 금지
신고

'TDD' 카테고리의 다른 글

[TDD] 정독완료..TestCase의 private 메소드.  (2) 2010.07.08
블로그코리아에 블UP하기
  1. Favicon of http://blog.doortts.com BlogIcon doortts

    2010.07.09 21:57 신고 [수정/삭제] [답글]

    안녕하세요? 많이 부족하고 부끄러운 책안의 글 정독해 주셔서 감사합니다. 그와는 별개로 (비록 일부분이긴 하지만) 저와 생각이 같은 부분이 있었다는 걸 알고는 더욱 반가웠습니다.

    읽으시며 아쉬웠던 내용, 기회 되실 때 알려주시면,
    배움의 하나로 알고 감사히 듣겠습니다. 그럼, 편안한 주말 되세요.

    감사합니다.

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.07.10 05:49 신고 [수정/삭제]

      오우~ 이렇게 직접 블로그까지 찾아와 주시다니 정말 감사드립니다.~**
      Agile과 TDD에 관하여 몇 해동안 탐독중, 그렇게 정성이 깃든 TDD관련책은 한국에 별로 없었던 것 같습니다. 때에 따라서 시도해 보려다가 포기한 기법들도 책속에 있어서 제 자신을 다시한번 반성하게 만들었습니다.(실무속에서 제가 경험했던 아쉬운 부분들도 대체적으로 책속에서 지적을 해 주셔서 매우 공감이 되는 부분이 많았습니다. 무조건 TDD를 맹신하는 것은 좋지 않다는 생각도 저랑 비슷했구요.
      앞으로 저의 부족한 소견까지 받아주신다면 정말 즐거운 이야기를 할 수 있지 않을까 합니다**)

      다시한번 찾아주셔서 깊은 감사를 드립니다.

      주말 편하게 보내세요~~**

댓글을 남겨주세요.

티스토리 툴바