🚀 3단계 - 테스트를 통한 코드 보호

[jinan159]

규남님 안녕하세요.
수강생 김진완 입니다.

오랜만에 리뷰 요청 드립니다😅

시간 관계상 통합테스트는 작성하지 못했고, 애플리케이션 서비스의 단위테스트만 작성했습니다.

---

아래는 테스트 케이스들 입니다. (총 60개)

[kyucumber]

요구사항 별 누락 없이 꼼꼼하고 깔끔하게 테스트를 잘 작성해주신 것 같네요.

간단한 코멘트 남겨두었으니 확인 후 요청 주시면 머지하도록 하겠습니다. 🙇

[kyucumber]

JpaRepository와 도메인의 레파지토리를 잘 나누어주셨네요 👍

[kyucumber]

ProductRepository와 같은 레파지토리들이 도메인 패키지에 있는 것은 이해가 가는데요, 인터페이스긴 하지만 사실상 Jpa와 직접 연관되어 있기 때문에 domain 영역이 아니라고 볼 수 있을 것 같아요. 이에 대해 어떻게 생각하시나요?

[jinan159]

말씀하신대로, Jpa 관련 기능이다 보니 domain 보다는 infra 영역에 있는게 어울릴 것 같습니다!

[kyucumber]

FindAll이나 Create와 같은 메서드 단위로 나누게 되는 경우 이후 많은 메서드가 생기면 테스트 클래스가 너무 많아질 것 같아요.

조회 / 수정 / 삭제와 같은 단위로 나누거나 혹은 복잡도가 높아지는 시점에 클래스 자체를 나누는 것도 방법일 것 같습니다.

[jinan159]

조회 / 수정 / 삭제 단위로 나누거나, 하나로 작성했다 복잡도가 높아지는 시점에 분리하는 방법도 좋다고 생각합니다!
다만, 각 기능(메서드)마다 필요한 Fixture 의 상태나 테스트 조건이 조금씩 달라서, 분리하기 위해 별도의 클래스로 나눴었습니다.

이처럼 클래스를 많이 나누게 되면 발생할 수 있는 단점을 생각해보면,,
저는 당장 생각나는건 도메인 변경이 발생했을때, 수정해야하는 영역이 많아질 수 있겠다는 생각이 들었는데요.
하지만 클래스를 나눔으로서 테스트 작성과 관리가 용이한 장점도 있어서 저는 클래스를 나누는 선택을 했었습니다.

혹시 테스트 클래스가 너무 많으면 또 어떤 단점이 있을까요?

[kyucumber]

Fake를 이용해 테스트를 잘 작성해주셨네요. 👍