인프런 커뮤니티 질문&답변
작성한 질문수
테스트 코드
해결된 질문
작성
·
45
1
안녕하세요 좋은 강의 잘 들었습니다~!
강의를 모두 듣고 제공해주신 프로젝트를 쭉 확인하고 궁금한 점이 생겨서 문의를 남겨봅니다
저는 실무에서
도메인 모델과 엔티티 모델을 구분하지 않고
도메인 모델에 JPA관련 어노테이션을 모두 허용한 상태로 개발해왔습니다
물론 구분해서 개발해본적도 있었지만
컬럼 변경 등 다양한 변경사항에 대응할 때마다
도메인 모델과 엔티티모델을 둘 다 확인하고 변경해야하는 번거러움?이 생겼던거 같아서 클래스가 좀 지저분해지더라도 도메인 모델 하나로 개발하고 테스트 코드를 작성해왔었습니다
이번 강의에서 사용된 프로젝트의 경우
모듈과 패키지가 나눠져있어서 도메인 모델과 엔티티 모델이 분리되어있는듯 보이지만 제가 사용했던 구조와는 다른점이 있었습니다..!
도메인 모델은 강의에서 말씀하신 개념과 격벽그리고 행동에 대해 적절하게 표현하기위한 객체이지만 핵심 비즈니스 로직을 모두 포함하고 있는게 아니라 대부분 조회된 데이터를 개념에 맞게 변경하는 DTO? 역할을 하는것 같고
상태변경에 대한 로직은 엔티티에 구현하고 service 레이어에서 호출하는 방식으로 보여집니다
그렇지만 처음 보는 코드가 잘 읽힐정도로 충분히 설득력있는 구조라고 생각이 듭니다..
다만 테스트 코드가 있어야만 그 설득력이 완벽해질것 같다는 생각이 들었습니다
그래서 해당 프로젝트 구조를 더 이해하고 학습하기위해 테스트 코드를 작성해보려고 합니다
만약 저라면 ~Entity에 작성되어있는 상태변경에 대한 테스트 코드와 ~Service, ~Handler, ~Manager 등에 작성된 로직에 대한 테스크 코드를 작성할 것 같은데
강사님은 이러한 구조에서 테스트 코드를 어디까지 작성하시는지 또는 어떻게 접근하시는지 궁금합니다~!
답변 2
0
안녕하세요 승환님! 질문 감사드립니다!
강의를 보고 충분히 고민하고 생각해보고 계신 것 같아서 아주 보람차네요 😃
테스트 코드의 경우는 베스트를 기준으로 말하면 각 모듈별 테스트 완결성을 갖도록 테스트를 구성하면 좋다고 생각합니다. (모듈별로 테스트가 완료 된 상태라서 모듈 자체에는 우려가 적은 상태를 만드는 수준의 테스트)
제 경우에는 가능하면 많이, 필요한 부분에 테스트를 작성하는 전략을 씁니다
Service, Handler 구분 없이 필요하다면 단위 테스트를 작성하고, Service 의 경우는 필요 시 통합테스트를 통해서 추가 검증을 하기도 합니다 (연결 고리 부분 및 데이터에 대한 검증)
테스트는 여러 목적과 효과가 있지만 결국 우리가 만든 소프트웨어 배포를 누를때걱정이 되지 않아야한다고 생각합니다 😀
(추가로 당연한 것이지만 JPA Repository 나 이런 정적으로 검증이 되는 영역은 굳이 별개 테스트를 작성하지 않습니다! 이런 프레임워크나 라이브러리는 필요하다면 기능적 테스트를 작성해두는 편입니다. ex] JPA 변경감지가 잘 동작하는가? < 가 필요하면 작성)
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. 정승환님.
질문해 주신 내용은 도메인 모델과 엔티티 모델의 차이와, 이들을 기반으로 한 테스트 코드 작성에 관한 것입니다. 여러분이 실무에서 경험하신 방식을 바탕으로 강의 내용을 접하면서 새로운 구조의 필요성을 느끼신 것 같아요.
도메인 모델과 엔티티 모델
일반적으로 도메인 모델은 비즈니스 로직을 포함하고 있고, 엔티티 모델은 데이터베이스와 직접 매핑되는 구조로 이해됩니다. 하지만, 이 둘을 구분하지 않고 JPA 어노테이션을 허용한 도메인 모델로 작업할 때의 장단점도 분명히 존재합니다.
강의에서 사용된 프로젝트는 ‘개념’과 ‘격벽’을 통해 도메인 모델을 매우 명확하게 구분하고, 각 개념이 독립적으로 작동할 수 있도록 설계된 구조라고 할 수 있습니다. 이로 인해 코드의 가독성이 높고, 구조적으로 매우 설득력 있는 방식으로 보이는 것이죠.
테스트 코드 작성 전략
테스트 코드는 프로젝트의 안정성을 증대시키는 중요한 역할을 담당합니다. 프로젝트의 구조와 도메인에 따라 테스트의 범위와 깊이는 다를 수 있지만, 일반적으로 아래와 같은 접근을 추천드립니다:
엔티티(Unit Test): 엔티티의 상태변화를 추적하는 메서드에 대한 테스트를 작성해야 합니다. 이는 비즈니스 로직과 직접 연관된 메서드에 대해 그 로직이 제대로 구현되었는지를 검증하는 과정입니다.
서비스 레이어(Integration Test): 서비스 레이어의 메서드가 엔티티와 도메인 객체들을 적절히 활용하고 있는지를 테스트합니다. 이는 각종 의존성을 포함한 전체 과정의 동작을 확인할 수 있어야 합니다.
핸들러/매니저: 핸들러와 매니저에 구현된 로직 또한 테스트하여, 다양한 시나리오에서 코드가 의도한 대로 작동하는지를 보장합니다.
관련된 추가 자료와 참조할 수 있는 보다 구체적인 테스트 코드 작성 사례는 다음의 유사한 질문을 참고하시길 추천합니다:
이와 같은 테스트 코드 작성 전략은 강의에서 사용하는 설계 패턴과도 맞물려 프로젝트의 유지보수성과 확장성을 높이는 데 큰 도움이 될 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.