이규원님의 현실 세상의 TDD 깊은 곳, 6편 : Should i test private methods

테스트 주도 개발의 깊은 곳 6편, Should i test private methods다.

private 메서드를 테스트해야하는지 알아보는 시간이다. 

여기에 실습 관련 코드는 포함하지 않으니 

📖 자세한 내용이 궁금하면 이규원 님의 TDD 수강하는 걸 추천드립니다. 👍 

The RED : 이규원의 현실 세상의 TDD : 안정감을 주는 코드 작성 방법 | 패스트캠퍼스

---

http://shoulditestprivatemethods.com

-> 구글에서 검색해보면 해외에서도 private 메서드를 테스트해야하는지 많은 질문이 보인다. 오죽했으면 이런 사이트까지 만들었을까...

 

 

비공개 모듈 테스트

- 비공개 모듈 작성과 사용은 공개 모듈의 구현 영역

- 비공개 모듈 테스트는 공개 모듈 구현 노출

-> 공개된 인터페이스를 통해서 사용자가 사용을 하게 되는데, 테스트도 이와같다. 사용자는 알 수 없는 숨겨진 private를 억지로 테스트하려면 내용이 노출 될 수밖에 없다. 테스트가 숨겨진 내부에 강하게 결합하게 된다. 

 

비공개 모듈 동작에 대한 불안함

잊어라. 인생은 짧다. 공개 모듈 동작을 고민하라.

 

켄트벡의 설계 규칙

1. Passes the tests

2. Revaela Intention

3. No duplication

4. Fewest elements

-> 공개된 인터페이스만 신경쓰라는 의미다. 숨겨진 private 테스트는 낭비다.

---

후기 

처음 Nextstep, TDD 교육을 받았을 때가 떠오른다.

단위 테스트를 막 시작해서 private 테스트를 어떻게 해야할지 몰라서 리뷰어에게 private 테스트를 어떻게 해야하나고 물어봤고,

private 메서드는 신경쓰지 말라는 답변이 왔었다.  

당시에 빨리 진행해야겠다는 생각에 제대로 이해하지 않고 넘어갔었는데, 이번 시간에 제대로 이해하게 되었다.

private까지 테스트하는 것은 많은 시간과 자원을 소비하는 낭비이다.

어차피 사용자는 공개된 인터페이스만 사용하니 private는 신경 쓸 필요가 없다는 의미다.

 

테스트도구로 private 테스트를 보여주시고 설계 변경에 생기는 문제를 보여주신다. 

리팩토링이 되거나 하면 공개된 인터페이스는 변화가 없이 그대로 두고 내부구조가 많이 변경이 될거다.

불필요해진 private methods가 사라질 수 있다. 그러면 사라진 private methods의 테스트는 어떻게 될까? 실패하게 될 것이다.

 

객체지향 관련 서적들을 읽으면 나오는 공통적인 주장이 있다. 

바로 자주 변경되는 것은 캡슐화하라는 주장이다. 그런 의미로 private 테스트가 얼마나 불필요한 건지 이해가 된다.