[BE] Coupon생성자 중 createdAt, updatedAt을 받는 생성자를 추가 (by 레오)

[yenawee]

생성자에 createdAt, updatedAt 추가

이렇게 생각한 이유는 현재 Coupon의 생성자로는 Coupon 의 단위테스트가 불가능하다고 생각합니다. 현재 저희 테스트에 Coupon 에 대한 단위 테스트가 없더라구요. Coupon 로직 중 첫 방문 날짜를 구할 때 createdAt을 보는데요. 현재 저희의 생성자로는 해당 값이 null일 수 밖에 없습니다. 그래서 사실 단위테스트가 불가능하다고 볼 수 있죠.
생성자에 createdAt을 추가하지 않고 단위테스트를 진행하고자 한다면 실제 repository를 띄우고 save()를 통해 createdAt을 넣어야합니다. 그러나 이것은 도메인 단위테스트에 repository를 엮는 꼴이 되어버립니다. 그래서 저는 생성자 추가 vs CouponStatics단위 테스트에 repository엮기 중 전자인 createdAt, updatedAt을 받는 생성자를 추가하는게 좋다고 생각합니다.
createdAt, updatedAt을 받는 생성자는 테스트에서 밖에 쓰이지 않을 것 같은데요. 그러나 이게 비즈니스 로직을 담고 있는 메서드가 아닌 생성자라는 점과, 생성자를 추가함으로써 단위 테스트가 가능하다는 이점이 더 크다고 생각합니다.

API : 카페 사장이 고객 목록 조회 가능 (사장 모드)

GET /api/admin/cafes/{cafeId}/customers
Authorization: username@password Base64 (Owner)

HTTP/1.1 200 OK 

{
	"customers": [
		{
			"id": 1,
			"nickname": "윤생1234",
			"stampCount": 4,
			"rewardCount": 3,
			"visitCount": 10,
			"firstVisitDate": "YY:MM:DD",
			"isRegistered": "true",
			"maxStampCount": 5
		}
	]
}

[gitchannn]

흠...

[gitchannn]

더 좋은 방법은 없을까요?

[yenawee]

쿠폰의 단위테스트를 하려면 어쩔 수 없지 않을까요

[gitchannn]

createdAt, updatedAt은 대개 데이터베이스에 예의 상 넣어두는 경우가 많은데,
우리가 이걸로 비즈니스 로직을 끌고 들어와서 이렇게 하고 있는 것 같다는 생각...

[gitchannn]

결론

Coupons 없앤다.

CouponStatistics 없앤다.

Histories(일급컬렉션)를 만든다.

Histories를 구하는 로직을 통째로 VISIT_HISTORY를 통해서 구하자 (첫 방문일, 방문 횟수)

나머지 reward_count, max_stamp_count는 서비스 레이어에서 잘 조합해서 만든다

histories.getFirstVisitDate(), histories.getStampCount()

[gitchannn]

담당자: 레오

[yenawee]

이 API 에서 반환하는 스탬프 개수가 총 스탬프 개수가 아니라 고객이 현재 가지고 있는 스탬프 개수였어서 내용 좀 수정

[gitchannn]

각자 생각 쓰레드

[yenawee]

Histories 일급컬렉션으로 책임 위임하고
created at 받는 생성자 만들기

[jundonghyuk]

생성자 만드는거 동으으으의~

이렇게 시간을 기준으로 로직을 짜야되는게 있으면 LocalDateTime.now 를 직접 생성자에 넣어줘도 되지 않을까 ? 라는 생각

[gitchannn]

• Visit History를 통해서 사용자 통계를 생성한다.
• 객체에 메세지를 던지는 형태로 최대한 작성한다.
• 필요하다면 Visit History에 createdAt을 받는 생성자를 추가한다.

[youngh0]

• VisitHistory에서 createdAt을 받는 생성자를 만들고, 객체지향적인 코드를 작성하는게 좋아보입니다.
  • 테스트를 위한 생성자이지만, 중요한 비즈니스 로직을 건드는게 아니기 때문입니다.