🧐 테스트, 왜 하지?
테스트 코드를 작성하기 위해 프로덕션 코드를 작성하는 시간보다 더 많은 시간을 쏟는 경우도 있다.
그리고 경우에 따라선 비즈니스나 프로덕션 코드가 변경됨에 따라 테스트 코드도 함께 날라갈 수 있다.
그럼에도 왜 할까?
내가 생각하는 가장 큰 장점 2가지는 다음과 같다.
- 내가 구현한 기능이 의도대로 동작하는지 가장 쉽고 빠르게 피드백 얻을 수 있다.
- 테스트 코드가 존재하면 의도대로 동작하는지 항상 확인받을 수 있으니 리팩터링 시 두려움이 없다.
🧐 영속 계층 테스트는 왜 할까?
우선 영속 계층은 뭘까?
그 전에 영속 계층은 무엇을 할까?
영속한다. 무엇을? 데이터를
결국, 데이터를 영속하는 역할을 가진 객체들이 모인 계층이다.
테스트 해야할까?
했을 때 장점은 크게 와닿진 않는다.
그런데 안한다고 가정했을 땐 꽤 솔깃하다.
만약 사용중인 DB 서버가 죽었거나 작성한 쿼리가 잘못됐거나 DB 연결이 잘못됐거나 등등..
하나의 Infra인, DB를 사용하는 상황에서 내 의도대로 동작하는지 확인하는 것은 큰 메리트가 된다.
(CRUD만 존재하는 Spring Data JPA라면 굳이..?)
그럼 어떻게 할까?
@DataJpaTest를 사용하는 테스트가 좋아보인다.
왜? 영속 계층만 테스트하는데 필요한 Bean만 등록해서 빠르게 하려고!
🧐 서비스 계층 테스트는 왜 할까?
서비스 계층에 대해선 진짜 레벨 2부터 고민을 해왔지만, 아직도 명확히 모르겠다..
처음엔 Mocking을 접하고 "서비스 계층은 '행위 테스트'를 하는게 적절하다!"
라는 이야기를 들었을 땐, "아니 굳이 알아서 메서드 호출하는 걸 테스트까지 해야하나?" 싶다가도
요즘엔 "아 행위 테스트, 유의미하지. 모든 메서드를 호출해준다는 보장이 어딨어" 라는 생각이다.
우선 서비스 계층은 뭘까?
음.. 다른 계층에 비해 굉장히 하는 일이 많다. 때문에 추상적이게 느껴지기도 한다.
그래도 분명한건 중간에서 비즈니스 로직 '처리'를 관장한다.
이 말도 조금 애매한게 엄밀히 말하면 도메인 객체들이 비즈니스 로직을 처리하기 때문인데
음.. 그냥 서비스가 그 로직들을 실행시키는 마치 매니저? 역할이라고 생각된다.
그럼 다시, 왜 할까?
위의 매니저라는 비유가 꽤 괜찮은 것 같아서 내가 점장이라 생각하고 매니저를 테스트한다고 생각해보면
지나가다가 가끔씩 "일 잘하고 있지? 밑에 애들은 일 잘하고? 별일은 없고?" 정도만 물어볼 것 같다.
결국, 내가 시킨 일들을 시킨대로 잘 수행하는지 확인하기 위해?
해야 할까..?
잘 모르겠다.
DAO, 도메인 수준의 단위 테스트, 인수테스트만 하면 컴팩트하게 웬만한 기능들을 꼼꼼히 테스트할 것 같은데.
아직 서비스 테스트를 해야하는 필요성을 못느껴서 그런가 이유를 잘 모르겠다.
추가로 서비스 계층을 mocking하면 내부 구현이 테스트 코드에 반영될 수 밖에 없다.
이는 테스트 코드가 구현 코드에 강한 의존성을 띄게 되고, 곧 경제성이 떨어지는 행위라고 판단된다.
그냥 위에서 말한 것처럼 모든 메서드를 제대로 호출해준다는 보장이 어딨냐는 생각으로 행위 테스트를 하는 선으로만 생각하고 있어야겠다.
🧐 Controller 계층 테스트는?
개인적으로 현재까진 불필요하다고 생각한다. 왜냐면 인수테스트로 충분히 할 수 있으니까!
뭐.. 나중에 생각이 다시 바뀔수도?
