본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 6일차!
오늘은 커뮤니티 피트 서비스의 유저 도메인 테스트 코드를 작성하는 작업을 진행하였다.
강사님께서 테스트 클래스에는 public 접근제어자를 사용하지 않고 접근 제어자를 생략한 상태로 두는 것이 좋다고 말씀하셨는데, 그 이유가 궁금해져서 따로 더 찾아보았다.
JUnit 등의 테스트 프레임워크는 reflection을 활용하여 테스트 케이스를 동적으로 로드하고 실행(@Test 어노테이션이 달린 메소드를 찾아내 테스트를 수행한다)하기 때문에 테스트 클래스에 public 접근 제어자를 사용하지 않아도 된다.
또한, 프로덕션 코드와는 무관한 내부 구현 검증용 코드를 불필요하게 외부에 노출하는 것을 방지할 수 있는 장점이 있기에 public으로 선언하지 않는 것이 좋은 방법이라고 한다.
빠르게 테스트 코드 작성이 가능하고, 테스트 중복이 줄어드는 장점이 있기에 바로 도메인 객체를 테스트하지 않고 객체 안의 객체들을 먼저 테스트하는 것이 좋다. 물론, ATDD(인수테스트 주도 개발)라는 방법도 있는 만큼, 프로젝트에 맞는 테스트 방법을 선택하는 것이 중요하다.
나는 그동안 테스트 코드를 작성할 때 작은 단위들로 나누지 않고 Controller단의 테스트에서 한번에 모든 레이어의 테스트까지 진행하였기 때문에 작성 과정이 복잡했고, 불가피하게 Mock을 매번 사용하게 되었던 경험이 있다.
이번 강의를 통해 단위 테스트를 작성하는 법에 대해 더 알게 되었다.
private으로 접근 제어를 설정한 메소드의 경우 클라이언트에서 이 메소드를 사용하지 않기 위함인데, 이러한 private 메소드가 테스트 때문에 외부에 노출이 된다면 노출된 테스트 코드의 유지보수가 어려워지게 된다. 또한, 내부 객체들까지 코드에 결합이 되는 것이기 때문에 캡슐화가 어려워진다.
그러므로 private 메소드는 테스트를 지양하고, 꼭 내부 테스트가 필요하다면 객체 책임의 다시 한번 설계해보는 것이 좋다.