private method test 기능을 테스트할까? 구현을 테스트할까?

서비스 레이어에서 테스트를 작성하다 private 메서드 테스트의 범위는 어디까지가 적당할까 라는 생각이 들었다.

 

OKKYCon TDD 레퍼런스에서 구현을 테스트하지말고 기능을 테스트 해야한다는 발표를 봤던 것이 생각나서 의문이 들었다.

 

Junit에서 private 메서드를 테스트 할 때 Reflection으로 해당 메서드를 받아와서 실행시킨 결과를 테스트하는 코드를 작성하는데 문제는 이 멤버 메서드를 가진 Service클래스 구현체가 다른 것으로 바뀐다면 바뀐 구현체의 public 메서드에서 별도로 추출한 private 메서드가 생길 것이고 기존의 사용하던 구현체의 private 메서드와 이름과 파라미터가 같지 않으면 테스트가 깨질 것이다. 

 

코드를 통해 예시를 보자면

 

추상화를 위한 인터페이스

TestService라는 인터페이스를 우리가 사용하기 위해 구현체로 TestServiceImpl1이라는 클래스를 만들었다고 가정해보자 

 

TestServiceImpl1 

앞서말한 조건을 위해 일부러 구현체의 오버라이딩된 메서드에서 코드가 복잡해졌다고 가정하고 private 메서드로 추출했다.

 

그리고 추후에 바뀔 구현체도 하나 만들었다. 

TestServiceImpl2

곱하기를 처리하는 방식이 다른 메서드를 가진 구현체이다.

 

이제 이 두 구현체를 테스트 해보자 

 

 

테스트 결과는 통과

 

 

그럼 이제 각각의 TestService 레퍼런스 객체에 끼워넣은 구현체를 서로 교체해서 테스트를 해보자 

 

서로 바뀐 TestServiceImpl

물론 결과는 fail이 나온다. 

테스트 실패

 

그렇다면 private 메서드의 테스트는 구현을 테스트하는 것 아닐까?

 

private 메서드를 public 메서드로 바꿔서 테스트하는 방식도 있겠지만 그건 옳지 않다.

 

기존에 작성해둔 테스트들이 구현체 하나의 변경으로 인해 모두 깨져버린다고 해서 다시 깨진 테스트를 새로운 구현체의 private 메서드 Reflection으로 고쳐서 통과시키는 것에 의미가 있을까 라는 생각이 들었다.

 

구현체를 바꿀때마다 깨지는 테스트는 내가 생각하는 테스트의 장점인 심적인 안정감을 주지 못하는 것 같다..

 

private 메서드를 사용하는 인터페이스 public 메서드의 테스트까지 진행하는 것이 구현을 테스트하는 것이 아니라 기능을 테스트하는 마지노선 이라고 생각한다. 

 

일단 아직 private 메서드까지 전부 테스트해서 좋은 점은 테스트 커버리지 100%가 가능하다는 것 정도로 생각이 드는데 혹여 글을 읽는 독자분들 중 관련하여 생각이 깊으신 분은 피드백이나 일침을 부탁합니다.