6주차 스프린트 주간회고

주간 작업 목표

 :  결제하기 와 장바구니를 구현하기

 

1. 결제하기는 기존에는 무조건 결제가 되는 식이였지만 카카오페이 API를 연동

2.  장바구니 추가

      1. CRUD 기능과 일괄 삭제 , 일괄 주문 기능까지 추가

+  카카오 서드파티 로그인 구현하기

 

 

사용자 스토리	작업명	예상	실제	비고
결제를 편리하게 하기 위해서 카카오페이를 사용할 수 있다.	주문 페이지 만들기	3	5	다음 주소찾기 API를 사용하는데 시간이 생각보다 많이 걸림
	카카오페이 결제 API 연동	20	24	DTO의 getter에 get~~로 안해서 그것 찾느라 시간이 좀 걸림....
여러개의 상품을 구매하고 싶은 사용자는 장바구니 에 물품을 추가할 수 있다.	장바구니 물품 추가	3	2
	장바구니 물품 삭제	3	2
	장바구니 물품 일괄 삭제	7	10	전체 선택 기능 때문에 애를 먹었다
	장바구니 물품 옵션 수정	7	5
	장바구니 물품 일괄 주문	5	10	여러개의 상품을 구매하는 경우를 생각하지 않고 주문페이지를 만들었다가 시간이 오래걸려버림..
총합		52	60

 

벌써 다음주가 마지막 스프린트이다.

 

어떻게든 다음주 까지 디자인 까지 입혀서 완성을 시켜야 하기 떄문에 일단은 무조건 빠르게 기능을 구현해야 한다는 목표를 잡았다. 

 

 

반성 

 

솔직히 이번 스프린트는 이전에 약속했던 원칙을 지키지 않았다. 테스트 코드 및 인수테스트를 무조건 작성하면서 할려고 했는데 테스트를 만들면서 하면 시간이 너무 잡아 먹힌다. 테스트를 거의 작성을 하지 않았다...

 

테스트는 분명 개발을 잘 하기 위해서 하는 것인데 너무 UI에 대한 테스트가 많아지니까 조금 만 내용이 바뀌고 props하나만 바뀌어도 테스트 를 10개씩 수정해야 하는 상황이 발생하기도 한다. 이런 상황 때문에 이런 고민이 들었다. 테스트 케이스가 100개 넘게 있는데 사실 이중 대부분은 UI에 대한 것이다. 그리고 UI는 프로젝트의 기획이 바뀐다면 언제든지 바뀔 수 있기 떄문에 오히려 비효율적이 되버렸다.

 

카카오 로그인을 구현하면서 주문 페이지의 배송지 정보에 대한 페이지를 수정을 해야 하는 상황이 있었는데 이 부분도 사실 상 테스트를 전부 다 고쳐야 한다. UI는 언제든지 그리고 자주 바뀔 수 있는 것이 지만 로직은 UI보다는 비교적 변화가 잦는 일은 없다.

 

또 UI는 전통적으로 테스트를 하지 말라는 격언이 있기도 하다. 그렇다면 프론트엔드에서 진짜 테스트를 해야하는 것은 어떤 것일까? 비즈니스 로직을 테스트를 해야하는데 상태를 관리하는 바로 스토어에 대한 테스트 그리고 단위 테스트에서 UI를 그렇게 테스트를 할 필요가 없는게 

 

UI에 대한 테스트는 인수 테스트에서 사실 거의다 커버가 되는 것 같다. 아니 오히려 UI에 대한 테스트를 만들어도 생각지 못한 부분을 인수 테스트를 하면서 잡아낸게 많았다. 

 

 

프론트엔드 테스트 코드를 어느 영역까지 해야할지는 이제 고민을 좀 해봐야 할 것 같다. UI에 대한 테스트는 최소화 하되 상태를 변화 시키는 동작을 집중적으로 테스트를 통해 검증을 해보자..

 

 

이제 다음 주 가 마지막인데 ㅋㅋ 이제 진짜로 잠잘 시간도 아깝다. 최소한 완성은 해보자!!!