[feat] 구매자는 매장 리스트를 조회할 수 있다

[Hyeon-Uk]

💡 다음 이슈를 해결했어요.

Issue Link - #74

• 구매자는 페이지별 매장 리스트를 조회할 수 있습니다.
• Store의 카테고리를 이용해 필터링
• Store의 MIN_ORDER_PRICE를 이용해서 필터링
• Store의 MIN_ORDER_PRICE를 이용해 정렬(오름차순/내림차순)
• Store의 OrderCount를 기준으로 정렬(오름차순/내림차순)
• 기본 사이즈(20)로 paging처리 가능

💡 이슈를 처리하면서 추가된 코드가 있어요.

• StorePageableFilterSortArgumentResolver : 페이징, 필터링, 정렬에 필요한 값들을 바인딩해서 넘겨줄 수 있는 ArgumentResolver입니다.

• StorePFS : 바인딩하기 위한 어노테이션입니다.

• StoreSortBy : Store의 정렬 기준을 관리하는 Enum클래스입니다.

• StoreFilterBy : Store의 필터 기준을 관리하는 Enum클래스입니다.

• StoreInfoListRequestConst : 가게 정보 리스트를 조회할 때 필요한 값들의 Key값과 Default값들을 관리합니다.

• StoreInfoListRequest : 필터링, 정렬, 페이징 조건들이 실제로 바인딩 될 클래스입니다.

• StoreInfoListResponse : 필터링, 정렬, 페이징을 거친 뒤, 클라이언트에게 전달해줄 데이터를 가지고 있는 클래스입니다.

• StoreDao : 동적 쿼리를 이용해 조건에 맞는 Store를 찾는 Data Access Object입니다.

💡 이런 고민을 했어요.

• StoreDummiesFixture :

1. 실제로 동적쿼리가 잘 나가서 기준에 맞게 return되는지 테스트해보려면 모든 레이어를 통합해서 테스트해야 합니다.
2. StoreDao 객체를 테스트하는 코드와, StoreApiController에서 Dao를 이용해 조회하는 부분 모두 동일한 조건의 더미데이터를 중복해서 사용합니다.
3. 이때 더미데이터를 매 메서드마다 혹은 실제 테스트 클래스에 노출시키게 된다면 코드가 길어지고 중복코드도 길어질것이며, 도메인이 변경된다면 StoreDaoTest 와 StoreApiControllerTestWithDao 를 모두 변경해야 합니다.
4. 따라서, 공통 더미 데이터를 생성할 수 있는 StoreDummiesFixture 를 생성해서 추후 도메인 엔티티의 구조 및 제약조건이 변경되더라도 Fixture만 변경하면 되고, 테스트 클래스에는 실제 테스트 로직만 보여질 수 있습다.

✅ 셀프 체크리스트

• 내 코드를 스스로 검토했습니다.
• 필요한 테스트를 추가했습니다.
• 모든 테스트를 통과합니다.
• 브랜치 전략에 맞는 브랜치에 PR을 올리고 있습니다.
• 커밋 메세지를 컨벤션에 맞추었습니다.
• wiki를 수정했습니다.

[Hyeon-Uk]

2fe2e49 커밋 메세지 오류입니다.

[fix] Store : StoreCategory 는 1 : N이기 때문에 OneToOne -> ManyToOne으로 수정 -> [fix] Store : StoreCategory 는 N : 1이기 때문에 OneToOne -> ManyToOne으로 수정

[kimhyun5u]

고생하셨습니다!!

[june-777]

궁금한점 코멘트 남겼습니다!!!

[Dr-KoKo]

이전의 PR에서 Order의 생성자가 변경되다보니 충돌이 나는 것 같네요.
테스트 코드에서 new Order(Customer,Store)를 사용하는 코드를 mock(Order.class)해서 사용하면 될 것 같습니다.

[Hyeon-Uk]

이전의 PR에서 Order의 생성자가 변경되다보니 충돌이 나는 것 같네요. 테스트 코드에서 new Order(Customer,Store)를 사용하는 코드를 mock(Order.class)해서 사용하면 될 것 같습니다.

감사합니다! 모든 Comment를 해결한 뒤 충돌 처리하면서 적용하겠습니다! :)

[june-777]

LGTM 🚀🚀