인프런 커뮤니티 질문&답변
작성한 질문수
Service+Repository 통합테스트 관련 질문입니다.
작성
·
90
·
수정됨
0
요즘 서비스 계층 단위테스트를 위해 모킹과 fake 객체 구현을 공부하고 있습니다. 하지만 레포지토리를 일일이 모킹하는 코드를 작성하는 것이 빠른 피드백이 장점인 단위테스트로 의미가 있는지 의문이 들 정도로 시간이 많이 들더라고요. 그래서, 좀 더 효율적인 강사님의 방식을 따라가고 싶어 강의를 듣던 중 의문이 생겨서 질문드립니다.
1. 계층별 테스트 분리 기준에 대한 질문입니다.
컨트롤러, 레포지토리는 단위테스트, 서비스 계층은 레포지토리 부분과 통합테스트 이렇게 분리해서 진행하셨던 이유를 여쭤봐도 될까요?
서비스, 컨트롤러, 레포지토리 계층 각각 단위테스트를 작성하고 컨트롤러에서 레포지토리까지 한번 통합테스트를 작성하는 방법도 있을 것 같고, 묶어볼 방법은 몇 가지 더 있는 것 같습니다.
그런데 강의에서처럼 분리했던 게 가장 효율적이라고 생각하는 기준과 이유…. 이 분리 방식의 발견 과정이 너무 궁금하네요
2. 통합테스트 DB 관련 질문입니다.
서비스계층과 레포지토리 계층을 묶은 상태로 H2 같은 임베디드 데이터베이스를 사용하면 테스트 속도가 상당히 느리게 나오긴 합니다. 이런 부분은 어쩔 수 없이 안고 가는 것인가요? 그리고 운영이나 개발 DB를 postgress같이 H2말고 다른 걸 사용한다고 해도, H2로 통합테스트 테스트하는게 이점이 있을까요?
3. 서비스 계층 단위테스트 관련 질문입니다.
혹시, 부담이 안 된다면, 서비스 계층의 단위테스트가 중요도가 많이 떨어진다고 생각하시는 이유가 Fake든 Mockito를 사용한 Stub이든 데이터베이스를 흉내만 내는 테스트가 의미가 없다고 여기셔서 그런 것일까요?
부족한 질문 읽어주셔서 감사합니다!
답변 2
1
안녕하세요, hwang99 님!
1. 계층별 테스트 분리 기준에 대한 질문입니다.
컨트롤러, 레포지토리는 단위테스트, 서비스 계층은 레포지토리 부분과 통합테스트 이렇게 분리해서 진행하셨던 이유를 여쭤봐도 될까요?
2가지 관점일 것 같은데요.
첫 번째로 서비스 단위테스트를 하지 않았던 이유는, 말씀하신 것처럼 FakeRepository를 구성하는 리소스 대비 효과가 적다고 생각하기 때문입니다.
두 번째로 서비스 레이어에서 통합 테스트를 진행한 이유는, 비즈니스 로직은 서비스 레이어부터 시작하기 때문입니다. 컨트롤러는 사실 (현재 구조에서는) 얇은 층이고, 담당한 역할이 외부 세계와의 소통, 최소한의 데이터 신뢰도 보장 정도이기 때문에 단위 테스트로도 충분하다고 생각해요.
물론 여기에 더해 모든 층을 아울러서 테스트하는 통합 테스트, 더 나아가 인수 테스트도 할 수만 있다면 좋은 것이고, 복잡한 사용자 시나리오일수록 꼭 필요한 상황도 있다고 생각합니다.
2. 통합테스트 DB 관련 질문입니다.
서비스계층과 레포지토리 계층을 묶은 상태로 H2 같은 임베디드 데이터베이스를 사용하면 테스트 속도가 상당히 느리게 나오긴 합니다. 이런 부분은 어쩔 수 없이 안고 가는 것인가요? 그리고 운영이나 개발 DB를 postgress같이 H2말고 다른 걸 사용한다고 해도, H2로 통합테스트 테스트하는게 이점이 있을까요?
만약 항상 구동 중인 개발 DB에 테스트할 수 있다면 속도는 빠르겠으나, 여러 사람이 테스트할 경우 그 독립성을 보장해줄 수 있는 환경이어야만 할 것입니다.
시간과 공간의 제약을 고려하고 독립성을 보장하면서, 그나마 빠른 인메모리 데이터베이스로 H2가 가장 적당하다고 생각합니다.
물론 운영 DB와 H2와의 차이점 때문에 테스트가 어려운 케이스도 가끔 있습니다만 (ex. 스키마 차이) 그런 경우는 트레이드 오프로 감안하거나, 꼭 필요한 테스트 케이스라면 해당 케이스만 실제 운영 DB와 같은 종류의 DB를 구축하여 테스트하는 방식도 있겠습니다.
3. 서비스 계층 단위테스트 관련 질문입니다.
혹시, 부담이 안 된다면, 서비스 계층의 단위테스트가 중요도가 많이 떨어진다고 생각하시는 이유가 Fake든 Mockito를 사용한 Stub이든 데이터베이스를 흉내만 내는 테스트가 의미가 없다고 여기셔서 그런 것일까요?
저는 FakeRepository가 존재하는 프로젝트를 다룰 때, 매번 Repository 메서드를 하나씩 추가할 때마다 FakeRepository도 유지보수를 해야 해서 힘들었던 경험이 있는데요. 테스트만을 위한 코드를 작성한다는 느낌을 지울 수가 없었습니다 ㅎㅎ
물론 서비스 계층의 단위 테스트를 할 수 있다는 장점이 있겠지만, 제가 느끼기에는 FakeRepsitory를 관리하는 만큼의 효용은 없었던 것 같아요.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
1
안녕하세요, 인프런 AI 인턴입니다. hwang99님께서 남기신 질문에 대한 답변을 드리겠습니다.
- 계층별 테스트 분리 기준
강의에서 보여드린 방식은 각 레이어의 역할에 집중해 테스트하는 방법입니다. 컨트롤러는 외부 입력을 받아 적절하게 서비스 레이어로 전달하는지 확인하는 것이 주 목적입니다. 따라서 이는 웹 요청을 mock하여 단위 테스트로 수행할 수 있습니다.
반면 서비스 계층은 비즈니스 로직을 포함하며, 레포지토리와의 상호작용이 있기 때문에 통합 테스트를 수행하는 것이 일반적입니다. 이렇게 하면 실제 데이터베이스와의 상호작용을 포함한 비즈니스 로직 전체를 검증할 수 있습니다. 이 방식이 효율적이라고 느끼는 이유는, 각 레이어에 필요한 검증을 하고 서로 간에 결합도를 낮추어 문제를 빠르게 파악할 수 있기 때문이에요.
- 통합 테스트 속도
H2 같은 임베디드 데이터베이스를 사용하는 통합 테스트는 아무래도 실제 데이터베이스와의 연결과 초기화 시간 등을 포함하여 느릴 수 있습니다. 이는 빠른 피드백이 중요한 단위 테스트와는 다르게 통합 테스트의 특성 때문입니다. 하지만 테스트의 목적에 따라, 즉 실제 DB와의 상호작용을 검증하는 경우에는 필요할 수 있습니다. 테스트의 목적에 따라 적절한 타협이 필요합니다.
- 서비스 계층 단위 테스트 중요도
서비스 계층 단위 테스트의 중요도는 프로젝트의 특성에 따라 달라질 수 있습니다. Fake나 Mockito를 사용한 Stub을 통해 단위 테스트를 수행할 수 있지만, 이는 데이터베이스와의 실제 상호작용을 완벽히 재현하지 못합니다. 따라서 프로젝트의 목적이 비즈니스 로직을 검증하는 것에 있다면 통합 테스트가 더 적합할 수 있습니다. 그럼에도 단위 테스트를 통해 비즈니스 로직의 일부를 검증할 수 있는 가치는 여전히 있습니다.
유사한 고민을 다루는 질문이 있습니다. 참고하시기 바랍니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
덕분에 효율적인 테스트 방법에 대해 한걸음 더 다가간 것 같습니다. 답변 감사합니다!