컨트롤러, 서비스 레이어 테스트를 SliceTest로 진행할 것인가? 아니면 통합테스트로 진행할 것인가

[Libienz]

여러 맥락을 포함하는 레이어의 테스트 범위를 얼만큼 지정할 것인가 🤔

[Libienz]

리비 발제 의도

• 레벨 2 미션에서 코드리뷰를 받을 때 리뷰어와 슬라이스 테스트/통합테스트 관련해서 이야기할 기회가 있었음.
• 얘기했던 모든 리뷰어들은 본인의 팀에서 통합테스트를 진행하고 있다고 대답했다.
• 사실 테스트 방식에 있어서 슬라이스 테스트와 통합 테스트는 런던파와 고전파라는 키워드로 나뉠 만큼 트레이드 오프 지점이 명확하다고 생각.
• 그런데도 여러 크루들, 그리고 리뷰어들과 이야기 했을 때 통합테스트 한 쪽으로 의견이 치우치는 현상이 신기했다.
• 개인적으로는 슬라이스 테스트를 선호하고 슬라이스 테스트만의 장점이 있다고 생각해서 오늘 토론 통해 의견 나눠보고 싶다.

리비 의견: 슬라이스 테스트 선호

• 스프링의 경우 테스트 컨텍스트를 가볍게 함으로써 실행시간을 줄이는 이점을 가져갈 수 있다.
• 실행시간을 줄이는 것이 CI서버의 부담을 줄이는 효과까지 있다고 생각.
• 또한 테스트 범위를 좁힌 슬라이스 테스트가 모이면 통합 테스트와 같은 효과를 낼 수 있기에 단점이 크게 체감되지 않는다.

콜리 의견: 통합 테스트 선호

• 테스트 관리적인 차원이나 테스트 의의에 통합테스트의 성격이 더 중요하다고 생각.
• 테스트 대역을 사용하면 협력 객체의 구현이 바뀔 때마다 테스트 대역의 동작을 수정해야 함
• 슬라이스 테스트는 테스트 범위가 좁다. 다른 실제 객체와의 협력까지 테스트 하는 것이 이상적이라고 생각

에버 주장: 통합 테스트 선호

• 둘 다 하는게 베스트라고 생각하지만 하나를 고른다면 통합 테스트!
• 스프링 단에서 슬라이스 테스트를 진행했을 때 큰 메리트가 없다고 생각한다.
• 예로 컨트롤러를 슬라이스 테스트로 진행하면 DTO가 잘 매핑되는지, 요청을 잘 받는지 등, 이미 스프링 단에서 검증이 끝난 요소만을 테스트 하게 될 텐데 이 지점이 별로라고 생각한다.

제리 주장: 통합 테스트 선호

• 통합 테스트를 이용하면 테스트 작성 과정에서 휴먼에러가 발생할 확률이 낮다.
• 그리고 테스트 대역을 쓰며 슬라이스 테스트 하는 경우 대역의 구현이 바뀔 때 테스트가 많이 깨진다.
• 또한 테스트 대역의 경우 하위 협력 객체의 구현을 세밀하게 알아야 한다.
• 즉 슬라이스 테스트는 하위 협력 객체의 구현을 모두 아는 상태에서 작성되어야 하고 깨지기 쉬운 지점이 단점이라고 생각한다.

슬라이스 테스트는 테스트 비용(실행 시간 등)이 저렴하다.

리비: 이전에 CI/CD를 알기 전까지는 테스트 비용의 중요성에 대해 체감하지 못했다. 하지만 이제 CI/CD를 프로젝트에서 경험해보게 되면서 테스트 비용도 무시 못할 수준이라는 것을 알게 되었다. 컨트롤러 테스트의 경우 슬라이스 테스트인 @WebMvcTest로 진행할 경우가 통합 테스트인 @RestAssured로 진행했을 때보다 11배 이상 빠르게 실행된다. 슬라이스 테스트에 비용적인 이점이 있다고 생각하는데 어떻게 생각하는가?

cf> 동일한 컨트롤러에 대한 슬라이스 테스트, 통합 테스트 비교

• @WebMvcTest: 70ms-80ms
• RestAssured: 850ms-940ms

• 콜리: 테스트 하고자 하는 범위가 다르니 시간이 다른 것. 동일한 범위의 테스트에서 성능을 달리하는 것이 아니기 때문에 슬라이스 테스트가 아예 우수하다고 말하기는 힘들 듯.
• 제리: 통합 테스트가 더 많은 리소스가 드는 시간 만큼 기능이 통합적으로 테스트 되기에 신뢰성을 얻었다고 생각한다.
• 에버: CI 서버의 부담보다 테스트의 신뢰성이 우선되어야 하는 가치라고 생각 트레이드 오프 지점인 것은 맞지만 통합 테스트의 가치가 여전히 더 크다고 생각한다.

슬라이스 테스트는 구성하기 쉽다.

리비: 통합 테스트의 경우 객체의 의존이 깊어지면 테스트를 위한 객체를 구성하는데에 많은 비용이 든다. 또한 통합 테스트는 실제 production과 환경을 일치하게 할 수 없기에 Config나 프로파일이 분리되기도 한다. 이는 엄연한 공수로 통합테스트를 힘들게 하는 요인들이다. 반면 슬라이스 테스트의 경우, 테스트 하고자 하는 범위 밖의 것들을 테스트 대역으로 간단히 처리할 수 있다. 어떻게 생각하는가?

• 제리, 에버, 콜리: 처음 작성할 때는 그럴 지 몰라도 후에 빈번하게 고치게 되는 쪽은 테스트 대역을 사용한 슬라이스 테스트라고 생각. 슬라이스 테스트가 오히려 공수가 많이 들 수도 있다.

슬라이스 테스트는 테스트 대상 범위가 좁아 신뢰성이 떨어진다.

제리, 에버, 콜리: 슬라이스 테스트는 테스트 대상 범위가 좁다. 하위 객체들과의 협력까지 검증하는 통합테스트의 경우 신뢰성이 높다. 반면 다른 개발자가 쓴 테스트 대역은 신뢰성이 떨어지고 더블 체크를 해야할 수도 있다.

리비: 잘 구성된 슬라이스 테스트들이 모인 다면 그것이 통합테스트라고 생각한다.

콜리: 자동차를 예시로 들어보겠다. 자동차의 엔진을 테스트하고 타이어등의 세부사항을 테스트한다고 해서 시운전 해보지 않고 차를 살 수 있겠는가? 통합 테스트의 필요성이 느껴지지 않는가?

리비: 반대로 물어보겠다. 자동차의 시운전이 잘 되었다고 엔진과 타이어등을 테스트하지 않을 것인가? 물론 둘 다 하면 제일 좋다. 그렇지만 둘 중 하나를 고르라고 한다면 나는 슬라이스 테스트를 고를 것이라고 말하는 것이다. 슬라이스 테스트가 모여 통합 테스트가 될 수 있다고 생각하고 무엇보다 슬라이스 테스트에서만 가능한 부분이 있다고 생각하기 때문이다.

에버, 제리: 통합 테스트를 사용하게 되는 경우 그 테스트 범위가 넓어짐은 단점이 아니라 장점이 될 수도 있다. 하나의 테스트를 작성함으로써 하위 협력 객체의 동작도 검증할 수 있다는 것이다. 테스트를 구성하는데에 있어서 단위테스트를 풀로 짜야한다와 같은 조건이 없는 것이다. 테스트 구성에 있어서 선택적인 옵션을 줄 수 있는 것도 통합테스트의 장점이라고 생각한다. 신뢰성이 가장 좋은 부분이긴 하다!

슬라이스 테스트는 리팩터링 내성이 낮다.

제리: 레벨 2미션에서 단계 별로 요구사항이 진화할 때 마다 슬라이스 테스트를 적용한 크루들의 테스트가 와장창 깨지는 것을 봐왔다. 리팩터링에 잘 견딜 수 있는 통합테스트가 좋은 것 아닌가?

• 리비: 요구사항이 변하면서 테스트가 실패하는 것은 자연스러운 현상이라고 생각한다.
• 에버, 콜리: 테스트가 실패하는 것은 자연스럽지만 안 깨져도 되는 테스트가 깨지는 것은 좋지 않은 부분이라고 생각. 사실 생각해보면 상위 레이어의 테스트는 깨질 필요가 없지 않는가?

토론 회고

• 리비: 역시 둘 다 상황에 맞게 사용하는 것이 정답이라는 생각이 든다. 다만 통합 테스트의 신뢰성에 대해서는 다시 한 번 생각해보게 되었다. (자동차 예시가 와닿았음)
• 에버: 처음의 의견과 마찬가지로 둘 다 적절히 사용하는 것이 가장 베스트라고 생각 다만 기본을 통합테스트로 할 것 같다. 테스트 비용적인 얘기에서도 설득되지 않았고 통합 테스트를 구성하는 데에 어려움을 겪었던 적도 없어 공감되지 않았다.
• 콜리: 몰랐던 관점에 대해서 알게 되었다. 하지만 아직은 통합테스트의 여러 가치가 더 크다고 판단한다.
• 제리: 통합 테스트가 아직 더 좋다고 생각하지만 리비가 느낀 통합 테스트가 불편하다고 생각하는 지점도 만나보고 싶다.