작성한 질문수 1

0

안녕하세요, yacheku 님!

1. 단위테스트할때 fake Repo를 커스텀하는 노력만 조금 들인다면 단위 테스트에대한 속도도 더빨라질거라 생각하는데 어떻게 생각하시나요?

어떤 형태의 단위 테스트인지, 커스텀을 어떻게 하실지는 모르겠지만, 잘 작성된 단위 테스트는 이미 속도가 충분히 빠른 테스트 방식입니다 ㅎㅎ 더 빠르게 한다고 해서 크게 (체감할 정도로) 효용성이 있을 것 같지는 않아요 🙂

2. fake repo를 만들때 list, map, set 중에 저는 map을선택하였는데 혹시 어떤것을 사용하시는지?

저는 FakeRepository 자체가 관리 포인트가 된다고 생각하기 때문에 애초에 선호하는 방법은 아닙니다만, 사용한다면 탐색 비용을 고려하여 map을 사용할 것 같네요.

3. 테스트 패키지 구조를 통합, 단위 라는 패키지를따로만들어서 넣는것보다
alt + insert로 만들기 쉽게 같은공간에 단위,통합이 존재하게하면서 Test, IT 라는 네이밍으로 클래스를만들고있는데 ex) OrderServiceTest, OrderServiceIT 우빈님은 어떻게 통합과 단위 패키지구조를 설계하시는지 궁금합니다.

단위와 통합인지에 따라 패키지를 구분하지는 않습니다. 패키지 구조 관점에서는 어떻게 테스트할 것인지 보다 무엇을 테스트하는지가 더 중요하기 때문에, 테스트 대상인 클래스 기준으로 자연스럽게 패키지를 잡고(프로덕션 코드의 패키지 구조를 그대로 따라가도록), 필요하다면 테스트 클래스 이름만 차이를 줄 것 같아요.

도움이 되셨기를 바랍니다.
감사합니다. 🙂

0

안녕하세요, 인프런 AI 인턴입니다. yacheku님 질문에 대한 답변을 드리겠습니다.

1. 단위 테스트에 Fake Repository 사용: Fake Repository를 이용해 데이터를 저장하고 조회하는 것은 실제 데이터베이스 접근을 피하면서도 빠른 속도로 테스트를 진행할 수 있게 합니다. 이러한 접근 방식은 단위 테스트의 속도를 크게 향상시킬 수 있습니다. 프로덕션 데이터베이스가 아닌 가벼운 컬렉션(List, Map 등)을 사용하여 동작을 모사하는 방식은 실제 데이터 처리 로직을 검증하기에 충분히 유효합니다.

2. Fake Repository에 사용할 컬렉션: Map을 선택하신 것은 좋은 판단입니다. Map은 데이터의 Key-Value 구조로 관리가 용이하고, 특정 엔티티를 ID나 고유 식별자로 관리하기에 적합합니다. 반면, List는 데이터 순서에 민감하고, 특정 요소를 빠르게 조회하는 데에는 다소 비효율적일 수 있습니다. Map을 사용하면 조회, 삽입, 삭제 등의 연산이 상대적으로 빠르기 때문에 효율적입니다.

3. 테스트 패키지 구조: 테스트 클래스와 통합 테스트 클래스를 하나의 공간에 두되, 네이밍 규칙을 통해 구분하는 방식을 택하셨군요. OrderServiceTest와 OrderServiceIT처럼 명명하여 단위 테스트와 통합 테스트를 구분짓는 것은 프로젝트 관리에 있어 효과적일 수 있습니다. 이렇게 하면 특정 클래스의 모든 테스트를 한눈에 파악할 수 있고, 필요할 때 특정 유형의 테스트만 빠르게 실행할 수 있다는 장점이 있습니다.

마지막으로, 다음 링크들을 참고하시면 비슷한 주제의 논의를 확인하실 수 있습니다:

• 단위테스트의 개념에 대해서 질문 드립니다!
  
• 마이바티스와 테스트 코드
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.