단위 테스트는 어느 정도까지 해야할까?
JPA 공부를 하다가 실습 테스트 코드를 작성중에 고민이 들었다.
아직 테스트코드 작성에 익숙하지 않고, 가장 베스트인 단위 테스트 코드가 무엇인지 고민해나가는 단계이다.
테스트 코드 작성을 익히기 위해 지난 회사 온보딩 기간에 인증서버 테스트코드 작성을 업무로 가져가면서 많은 검색과 고민을 반복했었는데 오랜만에 테스트코드를 작성하려니 새로 작성하는 기분이다.
entityManager를 사용해 간단하게 회원가입하는 로직을 테스트하려는 도중에 또 어느 정도까지 테스트 코드를 작성해주어야하는지 고민이 든다. (이전에도 같은 고민을 한 것 같기도 하다.)
단위테스트에 걸맞게 의존성을 최소화하기 위해 mocking을 해준다. repository가 mock객체이기 때문에 실제 db에 저장되지는 않을 것이며 그러면 저장된 값을 임의로 지정해주어 테스트해준다.
- 그렇다면 repository 로직에 대한 단위 테스트가 추가되어야할 것이다.
- 그리고 join 메소드는 반환값을 repository.save로 받은 값이 아닌 member.getId(member 객체는 join의 인자로 받는 값.)을 반환하도록 하는 것이 좀더 단위 테스트를 작성하기에 수월한 코드가 될것이다.
(왜냐하면 repository 반환값을 반환하도록 짜게되면, 단위테스트 시 실제 repostory는 null을 반환할 것이고(mock객체기 때문에)그러면 테스트 대상인 join 메소드의 반환값도 지정해주어야하는데 이렇게 반환되는 값들을 모두 지정해주는 것이 테스트의 의미를 더 퇴색시키는 느낌이라 생각했다.)
도메인 모델 패턴과 트랜잭션 스크립트 패턴
도메인 모델 패턴 - 비즈니스 로직 대부분을 엔티티에 작성하고 서비스 계층은 엔티티에 필요한 요청을 위임하는 역할의 형태로 객체지향의 특성을 적극 활용하는 형태.
트랜잭션 스크립트 패턴 - 엔티티에는 비즈니스 로직이 거의 없고 서비스 계청에서 대부분의 비즈니스 로직을 처리하는 형태.
그렇다면 둘 중에 베스트는 무엇일까 ? 혹은 두 패턴의 장단점은 무엇일까?
우선 내가 생각했을 때는 자주 사용되는 메소드의 경우 엔티티에 작성하는 것이 객체지향적이라고 생각이 든다. 다만 그렇지 않은 경우 비즈니스로직은 서비스 계층에 작성하여 엔티티와 서비스 레이어의 각 역할을 명확히 하는 것이 좋지않을까하는 생각이다.