역자 주: 이 글은 Charles Miller의 포스트 Testing private methods (don't do it)를 번역한 것입니다.
Peter Ghali는 프라이빗 메소드를 테스트하는 것에 대해 자신의 블로그 (역자 주: 링크 깨졌음)를 통해 저에게 물어봤습니다:
그러면, 어떻게 프라이빗 메소드를 테스트할까요? 제 생각은 프라이빗 메소드들은 전혀 테스트를 할 필요가 없다고 봅니다. 프라이빗 메소드들을 사용하는 퍼블릭 메소드, 프로텍티드 메소드들을 통해 이미 충분히 테스트가 됐다고 보거든요.
저는 프라이빗 메소드들을 테스트하지 않습니다. 프라이빗 메소드들의 기능들을 빠르게 만들고 옮기고 고치고 하는 것들은 애자일 개발 방법론에서 굉장히 중요하다고 생각합니다.
퍼블릭 인터페이스의 행위(behaviour)를 바꾸는 데에는 굉장히 높은 비용이 필요합니다. 인터페이스를 사용하는 모든 호출자들이 이러한 변화에 대응할 수 있는지에 대해 확신할 수 있어야 합니다. 가끔은 심지어 새로운 테스트 코드를 작성해야 할 때도 있습니다. 왜냐면 이전엔 없었던 극단적인 상황이 생길 수도 있기 때문입니다. 반면에 프라이빗 메소드들은 그것을 포함한 클라스를 테스트하면서 항상 테스트가 가능합니다. 만약 새로운 극단적인 케이스를 도입한다면 그 상황에 맞는 테스트 클라스만 작성하면 됩니다. 모든 것이 다 포함되어 있죠.
만약 당신이 프라이빗 메소드들을 테스트해야 한다면, 또는 프라이빗 메소드를 바꿀 때마다 테스트 코드를 다시 짜야 한다면, 그건 리팩토링에 있어서 커다란 장애물이 될 겁니다. 당신의 코드를 개선시키기 위해 해야 하는 일의 양은 프라이빗 메소드들을 바꾸기 위해 필요한 일의 양이 됩니다. 게다가 그것은 테스트 코드를 수정해야 합니다. 따라서, 결국은 당신의 코드를 개선시키는 데 주저하게 될 겁니다.
만약 당신이 공개된 인터페이스를 테스트하려고 한다면, 이러한 테스트 코드들은 저절로 해당 클라스 안의 프라이빗 메소드들이 잘 작동한다는 것을 확인합니다. 만약에 그게 아니거나, 프라이빗 메소드들이 너무나 복잡해서 외부 호출자와는 별도로 테스트를 해야 하는 상황이 된다면, 그건 당신의 코드에 냄새가 난다는 것을 의미합니다.
여기서부터는 내 생각.
지금까지는 퍼블릭, 프로텍티드, 프라이빗 상관없이 모든 메소드들을 테스트해야 한다고 생각했다. 리플렉션이라든가 하는 여러 가지 방법을 통해 할 수 있기 때문이다. 그런데, 프라이빗 메소드들은 목킹도 불가능하다. 왜냐면 테스트를 할 경우에는 보통 인터페이스를 통해 목킹을 해서 진행하는데, 프라이빗 메소드들은 인터페이스에 노출되어 있지 않으니까 이것들을 테스트 하려면 다른 꼼수들을 짜내야 하는, 배보다 배꼽이 더 큰 상황이 된 것이다.
그럼에도 불구하고 테스트를 해야 한다고 생각했는데, 굳이 그럴 필요가 없어졌다. 정말로 테스트를 해야 한다고 생각한다면 Should I test private methods or only public ones? 이 글에 답변으로 채택된 것에 나온 바와 같이 메소드 오브젝트 기법을 통해 리팩토링을 한 후 해당 클라스를 테스트하는 것이 나은 방법이 아닌가 싶다. (마틴 파울러 만세!)
아직도 여전히 한결같이 쪼렙이로구나. 흙흙