병연님 의견 [commit]
테스트 코드 관련
현재 도메인 테스트와 repository 테스트를 ${domain}RepositoryTest 로 함께 하고 있는데 이 부분까지 합치면 거의 200줄이 넘어갑니당. (현재 상황에서) 그래서 따로 분리가 필요해 싶어가.. 의견을 들어보고 싶습니다. 어떠신가용?
테스트 코드 영역
제가 생각 했을 때는, domain 대한 validation, 유효성 체크는 ${domain}Test 로 따로 작성하고 RepositoryTest에서는 repo에 대한 쿼리 기능 테스트만 하는 쪽으로 생각해봤습니다 ‼️
해당 방식은 어떻게 생각하시는지 궁금합니다. 그리고 네이밍 추천은 언제든 웨ㄹㄹㄹㄹ컴~ 입니당🙂
- 형욱
- 저도 동의합니다 ~ validation 여부는 {domain}Test로 분리해서 작성하고 Repository는 repo에 대한 curd 테스트에만 집중하면 더 좋을 것 같습니다 🙂
- Repository or Service에서도 하나의 파일에 코드의 길이가 너무 길어진다 싶으면 FollowRepository{행위..?}Test 이런 느낌으로 테스트 파일을 나눠서 작성하는 것도 하나의 방법이 될 수 있지 않을까 생각이 들었습니다. 하나의 서비스에 대해서 꼭 하나의 서비스 테스트 파일만 있어야 하는 건 아닌 것 같다는 생각이 들었습니다
- 진형님
- ${DomainTest} → ${domain}ValidationTest
- 패키지 명으로만 컨텍스트를 구분을 한다면 IDE의 검색기능 활용에 어려움을 겪을 수 있다.
동운님
- 혜빈
- ${domain} + ValidationTest라고 가져가면 안 되는건가
- 풀네임에 한 표
결정
${domain}ValidationTest , ${domain}RepositoryTest
Converter 빈 관리 (오늘 저녁 스크럼 6:10)
테스트 코드에서 Converter를 Mock 사용을 위해 의존성을 끊어내기 위해 설정을 해주는 부분에서
유틸성 클래스인 컨버터를 빈으로 관리할 필요가 있는가.
- 혜빈
- 빈을 사용하는 이유 : 멀티유저에 대한 동시성 제어가 중요하며 이를 위해 스프링 컨테이너에서는 싱글톤 패턴(Singleton Pattern)으로 관리한다.
- 위와 같은 이유가 converter에도 해당이 되는지 그런 경우가 잘 떠오르지 않습니다
- Post의 경우 너무 과중화 되어있고 이를 해결하기 위한 리팩토링을 진행 중입니다. 만약 컨버터가 빈이라면? 이미지 업로더도 빈으로 관리를 해야하는 건가 라는 생각이 듭니다.
- 현재 저희 프로젝트에서 postConverter가 다른 것으로 대체 될 가능성도 없다고 생각이 듭니다.
- 병연
- 의존성을 끊는 것을 찬성합니다! (스프링이 관리할 대상을 그만 만들자?)
- 한번 해보는 걸로
- 불특정 다수에게 요청함에 있어 포퍼몬스는 나중에 일이니 먼저 끊는 것을 추천합니다.
- 동운
- Service단 테스트인데 Converter 테스트인가 싶을 정도로 코드량이 많다고 느꼈습니다. 테스트 코드의 가독성도 그렇고, 서비스 단의 테스트라면 Service 로직 중심으로 작성되는게 좋지 않을까 싶습니다.
- Converter를 다 설정하지 않아도 되는 방법을 찾기 전까지는 의존성을 끊는게 좋아보입니다.
- 형욱
- 단순히 도메인과 DTO를 변환하는 작업을 하는 역할을 해주는데 차지하는 코드의 양이 너무 많은 것 같다는 생각이 듭니다.
- 의존성을 끊는다고 해서 어떤 부분에서 문제가 생길 일이 있을까 생각을 해봤을때 아직 떠오르지가 않는 것 같습니다. 따라서 저는 컨버터는 의존성을 끊어줘도 되지 않을까 생각이 듭니다.
- 진형
- new로 하는것도 괜찮다고 생각함다.
- 이미지 업로더는 Static으로 구현되어있는데 이렇게 해도 S3으로 스무스하게 변경되나요?
- 인터페이스를 먼저 생각하고 내부 구현체를 변경하는식으로 해야되지 않을까요?
- Converter를 빈으로 관리하고 테스트코드에서 new를 사용하는 방법도 사용해봤었습니다.
결론
- 각자 맡은 도메인에서 더 좋은 방법이라고 생각되는 부분으로 진행해보기