인프런 커뮤니티 질문&답변
작성한 질문수
테스트 코드 작성 범위 고민
작성
·
140
·
수정됨
1
안녕하세요! TDD 평소에 관심이 많았지만 실무에서 막상 적용하려니 고민이 많았는데 좋은 강의 만들어 주셔서 감사합니다. 섹션5까지 수강했는데 벌써 만족스럽네요 수강평 5점 먼저 드렸고 평소에 실무에서 항상 고민이 되던 부분이 있어서 질문드려요!
테스트코드가 너무 많아지는 것이 부담스러워서 하는 고민인데요.
특정 Service 메서드의 테스트코드를 작성 할 때 해당 메서드가 사용하고 있는 Repository 메서드 에서 테스트한 내용을 Service 에서 중복적으로 테스트해야하는 가에 대한 고민입니다. 참고로 Service, Repository 메서드 둘다 응답에 영향을 미치는 동일한 파라미터를 인풋으로 받고 있다는 전제입니다.
GPT 에게 물어보면 아래와 같이 대답을 하는데요. 서비스 메서드의 인풋값이 변경되면 응답에 영향을 미치는데 Repository에서 테스트했다고 안하는 것이 맞는가? 라는 고민이 계속 되네요. 고견 주시면 감사하겠습니다!
[GPT 답변]
Service 테스트는 Repository 동작이 "올바르다고 믿는다는 전제 하에" 작성하는 것이 일반적인 전략입니다.
즉, Repository의 구현 자체를 Service 테스트에서 다시 검증할 필요는 없습니다.
질문 카테고리가 "수업질문"인데 전체질문으로 변경하는 버튼이 없어서 일단 그대로 둡니다 ㅜㅜ
답변 3
2
폭식님 안녕하세요. 좋은 평가에 질문까지 남겨주셔서 정말 고맙습니다.
우리가 시스템을 개발할 때 테스트 대상이 될 수 있는 코드는 많습니다. 그리고 그 중에서도 실제로 어떤 영역을 대상으로 테스트를 작성해야 하는지는 여러가지 상황에 따라 달라집니다. 여기서는 말씀하신 구조를 가정하고 제 의견을 말씀 드리겠습니다.
+--------+ +-----+ +---------+ +------------+
| Client | ---> | API | ---> | Service | ---> | Repository |
+--------+ +-----+ +---------+ +------------+
한가지 규칙만 있다면 참 쉬울 것 같은데요, 안타깝게도 그렇지는 않고 여러가지 상황 변수에 따라서 결정해야 합니다. 그래서 몇 가지 상황에 대해서 제가 선택할 수 있는 방법을 소개해드리겠습니다.
1. API 계층의 동작이 가벼워서 테스트 실행 성능에 큰 문제가 되지 않는 경우
우리가 응용프로그램을 개발하는 목적은 클라이언트의 요구사항을 만족하는 것입니다. 이 목적이 달성되는지 확신할 수 있다면 다른 작업들은 선택적입니다. 그래서 모든 요구사항을 클라이언트와 직접 만나는 API 대상으로만 테스트합니다.
+--------+ +-----+ +---------+ +------------+
| Client | ---> | API | ---> | Service | ---> | Repository |
+--------+ +-----+ +---------+ +------------+
^
|
Tests
2. API 계층 동작이 무거워서 테스트 실행 성능에 많은 영향을 미치는 경우
API를 대상으로만 테스트를 작성해서 클라이언트의 모든(또는 대부분의) 요구사항을 확인할 수 있더라도 테스트 실행에 너무 긴 시간이 소비되면 프로그래머는 심리적으로 테스트를 덜 자주 실행하게 되고 작업 리듬에 부정적인 영향을 받게 됩니다.
이 때는 Service 대상으로 테스트를 많이 작성해서 테스트 실행 성능을 관리할 수 있습니다.
Service 대상으로 최대한 많은 요구사항을 검증합니다.
API가 Service를 사용하는지 확인할 수 있도록 가장 간단한 성공 경우에 대한 테스트 하나를 작성합니다.
사용자 인증 등 API 계층의 책임인 기능을 검증하기 위해서 필요한 API 대상 테스트를 작성합니다.
+--------+ +-----+ +---------+ +------------+
| Client | ---> | API | ---> | Service | ---> | Repository |
+--------+ +-----+ +---------+ +------------+
^ ^
| |
Tests Tests
3. Service 계층 테스트에 Repository에 대한 테스트 대역(test double)을 사용하는 경우
어떤 이유로 인해서 Service 개체를 테스트할 때 운영 환경과 동일한 Repository가 아니라 mock 등 테스트 대역을 사용하는 경우도 있습니다. 이런 경우 Service 개체를 대상으로 테스트를 충분히 작성해도 테스트에 의해서 Repository 코드가 실행되지는 않기 때문에 Repository가 운영 환경에서 정상적으로 동작하는지 확신할 수 없습니다. 그래서 이런 상황이라면 Repository에 대한 테스트를 별도로 작성합니다.
+--------+ +-----+ +---------+ +------------+
| Client | ---> | API | ---> | Service | ---+------> | Repository |
+--------+ +-----+ +---------+ | +------------+
^ ^ | ^
| | | |
Tests Tests | Tests
|
| +------------------------+
+--> | Repository Test Double |
+------------------------+
이 강의 실습에서는 1번 방식을 사용하고 저는 실무에서도 자주 사용합니다. 그리고 2번의 방법도 실무에서 많이 사용하고요, 테스트 대역을 잘 사용하지 않기 때문에 3번 방법은 가끔씩만 사용합니다.
클라이언트의 요구사항을 검증하는 것이 테스트를 작성하는 가장 큰 목적이고, 엔지니어링 측면에서 문제가 있을 때 이를 해결하기 위한 기법을 추가 사용한다고 제 기준을 정리하겠습니다.
더 설명이 필요하다면 말씀해주세요!
1
안녕하세요, 상세한 답변 감사합니다. 테스트 코드는 리포지토리부터 작은 단위로 모두 작성해야한다는 고정관념을 가지고 있었네요. 답변해주신 내용이 너무 실용적이고 당연하다는 생각이 들면서 왜 그렇게 생각 못했을까 싶네요! 강의비가 아깝지 않네요! 너무 감사해요.
0
안녕하세요, 인프런 AI 인턴입니다. 폭식중인다이어터님.
TDD에 대해 깊이 고민하고 계신 것을 보니, 정말 열정적이신 것 같습니다. 특히 실무에서의 적용과 관련된 질문은 많은 개발자분들이 겪는 고민이기도 합니다. 질문해 주신 내용에 대해 좀 더 자세히 설명드리겠습니다.
Service와 Repository 테스트의 중복 여부
책임 분리 원칙:
- 일반적으로 Service는 비즈니스 로직을, Repository는 데이터 접근 로직을 책임집니다. 따라서, 각 계층에서의 테스트는 해당 계층의 책임에 맞는 동작을 검증해야 합니다.
- 일반적으로 Service는 비즈니스 로직을, Repository는 데이터 접근 로직을 책임집니다. 따라서, 각 계층에서의 테스트는 해당 계층의 책임에 맞는 동작을 검증해야 합니다.
Repository의 신뢰:
- Repository는 데이터베이스와의 상호작용을 직접 다루며, 이를 개별적으로 검증하기 위해 통합 혹은 단위 테스트를 작성합니다. Service 테스트에서 Repository의 동작이 ‘올바르다’는 전제를 갖고 진행합니다. 이는 깔끔한 계층 설계 원칙을 유지하고 테스트의 중복을 피하는 데 도움을 줍니다.
- Repository는 데이터베이스와의 상호작용을 직접 다루며, 이를 개별적으로 검증하기 위해 통합 혹은 단위 테스트를 작성합니다. Service 테스트에서 Repository의 동작이 ‘올바르다’는 전제를 갖고 진행합니다. 이는 깔끔한 계층 설계 원칙을 유지하고 테스트의 중복을 피하는 데 도움을 줍니다.
입력값 변화의 영향:
- Service의 입력값이 변경되어 결과에 영향을 미칠 가능성이 있다면, 이 변화가 비즈니스 로직에 어떠한 영향을 미치는지를 검증해야 합니다. 따라서, 중요한 것은 Repository 메서드의 세부 동작보다는, 최종적으로 Service가 반환해야 하는 결과가 기대치에 부합하는지를 테스트하는 것입니다.
- Service의 입력값이 변경되어 결과에 영향을 미칠 가능성이 있다면, 이 변화가 비즈니스 로직에 어떠한 영향을 미치는지를 검증해야 합니다. 따라서, 중요한 것은 Repository 메서드의 세부 동작보다는, 최종적으로 Service가 반환해야 하는 결과가 기대치에 부합하는지를 테스트하는 것입니다.
통합 테스트 활용:
- 만약 Service와 Repository의 상호작용 자체에 대한 확신이 필요하다면, 통합 테스트를 통해 Service 메서드가 Repository와 연동하여 올바르게 동작하는지 추가적으로 검증할 수 있습니다.
- 만약 Service와 Repository의 상호작용 자체에 대한 확신이 필요하다면, 통합 테스트를 통해 Service 메서드가 Repository와 연동하여 올바르게 동작하는지 추가적으로 검증할 수 있습니다.
테스트 범위에 대한 고민은 언제나 복잡한 문제이지만, 명확한 책임 분리와 각 계층의 테스트 목표를 분명히 하는 것이 핵심입니다.
유사한 질문과 답변을 더 보길 원하시면, 다음 링크를 참조하세요:
- “거짓 양성 감지 노하우 질문입니다”
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변이 도움이 돼서 다행이네요. 남은 섹션에서도 질문이 생기면 편하게 질문해주세요!