테스트 시 혼재된 생성 로직과 픽스처 사용을 픽스처 사용으로 통합

[jminkkk]

⚡️ 관련 이슈

close #1043

📍주요 변경 사항

현재 테스트에서 픽스처와 엔티티를 생성자로 직접 생성하는 부분이 혼재되어 있습니다.
도메인 설계 부분에서 템플릿 생성자가 변경될텐데, 변경사항이 매~~~우 많이 잡혔어요.

도메인 설계 변경하면서 동시에 작업하면 난장판이 될 것 같아 먼저 부분적으로 통합했습니다.
앞으로는 변경에 유연하도록 가급적 픽스처를 사용해주세요. 수작업 힘들었음

또 테스트 메서드에서만 사용하는 템플릿의 생성자가 있어서 제거했습니다.

급한 건 템플릿 쪽이라 템플릿과 회원, 소스코드 부분을 일단 통합했습니다.
참고 부탁드려요~

+) 추가적으로 category, member, template 연달아 저장하는 부분이 많은데 이 부분 중복제거가 필요할 것 같아요.
각 테스트에서 전혀 몰라도 되는 준비 과정은 메서드로 추출해도 될 것 같다고 생각했어요. (좋아요 검증을 해야하는데, 카테고리 같은 부분은 해당 검증에서 꼭 들어나지 않아도 된다고 생각)

중복이 너무 심합니다.

추가로 테스트 코드에서 공감되는 부분이 있어서 읽어보심 좋을 것 같아요 인프런 Q&A

해당 서비스 로직의 요청/응답에도 드러나지 않지만, 테스트가 정상적으로 동작하기 위해서 이미 생성되어 있어야 하는 fixture들은 setUp() 사용한다.

• 가정 : 하나의 매장을 해당 테스트 클래스 전체에서 공유해도 문제가 없고, 매장의 상태 변화에 관심을 가질 필요도 없을 때 (매장의 상태가 변하지 않을 때)

1. 매장을 생성한다.
2. 매장을 운영 상태로 만들기 위한 여러 설정값을 세팅한다. (운영시간 등)

여기서 저는 매장의 상태 변화 같은 게 우리의 템플릿의 카테고리 같이 비슷하다고 생각했어요.

🍗 PR 첫 리뷰 마감 기한

01/20 21:00

[zeus6768]

너무 좋네요 고생했어요 몰리!!! 🔥🔥🔥

[HoeSeong123]

헉 저도 작업하면서 이거 무조건 고쳐야겠다고 생각했던 건데 역시 몰리..
최고입니다👍

[kyum-q]

몰리 짱입니다 진짜~~~~~~!!!!

[zangsu]

몰리 고생 많으셨어요!!!
진짜 힘들었겠는데요~~~
몇가지 제안사항 코멘트로 남겨두니 확인해주세요~

@BeforeEach에 대해서~~

저도 몰리와 거의 동일한 입장이에요.
지금의 테스트 내용과 큰 관련이 없는 준비물들은 최대한 @BeforeEach를 포함한 별도 메서드를 활용하고 싶어요.
당연히 그 준비물들이 테스트 상황을 이해하는데 필요하다면 코드가 길어지더라도 테스트코드 내에 있어야겠지만요!

준비를 위한 코드가 길어진다면 특정 상황을 공유하는 여러개의 테스트코드를 @Nested로 묶는 것도 고려해도 좋을 것 같고요~~

[zangsu]

몰리~~~ 고생 많으셨네용 ㅋㅋㅋ
approve 남깁니다!!