sinon 테스트 코드의 문제
글로벌로 돌릴 때 다른 파일에 sinon mock 이나 stuff 가 있으면 인스턴스를 공유하는 문제로 테스트가 정상 동작하지 않음.
팀장님 코멘트;
이러니까 jest 쓰지...
우선 mocha 테스트 코드를 정상 동작하도록 개선하고 jest 로 이동하는 방향을 선택함.
테스트 코드의 중요성
V2 서비스 메인 코드인 shared 폴더의 구조를 개선하면서 느낀 점이라면 '리팩토링 이전에 테스트 코드를 반드시 준비할 것' 이다.
가상 계좌 입금 처리의 문제
그동안 뭉개고 있던 버그를 해결하고 instant 결제가 얼마나 편하고 좋은지 새삼 느낌.
가상 계좌 입금, 예전에는 무통장 입금이라고 부르기도 했다. 가상 계좌 결제는 주문 후 즉시 결제가 일어나지 않는다는 큰 특징이 있다. 인스탄트 결제와 비교해보면 다음과 같은 차이가 있다.
일반적인 카드 결제나 실시간 계좌 이체 또는 간편 결제 등은 그 구매의 주문과 결제가 1:1 로 매칭되지 않더라도 해당 주문에 대한 결제 정보는 입금 정보와 동일하다.
하지만 가상 계좌 입금은 주문에 대한 결제 정보와 입금 정보가 일치하지 않는 경우가 있다.
다음과 같은 시나리오를 생각해보자.
- 주문 A 완료
- 가상 계좌 결제 (가) 땡땡 은행 → A(가)1 이라 하자.
- 가상 계좌 결제 (나) 빵빵 은행 → A(나)2 이라 하자.
주문자는 땡땡 은행에 입금할 수도 있고 빵빵 은행에 입금할수도 있다. 정상적인 주문 결제 시스템은 어떤 은행에 입금을 해도 주문 A 가 정상 결제 되도록 구현해야 한다.
주문1:결제N 구조
이 구조는 상태적으로 단순한 편이다. 보통의 커머스는 이 구조를 바탕으로 설계를 하면 무리가 없다.
주문N:결제1 구조
이런 경우도 있다. 한 번의 결제로 다양한 주문을 처리할 수 있다.
주문N:결제N 구조
매핑하는 테이블이 필요하다. 만약 매핑하는 테이블이 없다면 대표 주문 정보를 각 결제 정보마다 가지고 있어야 한다.
우리가 가진 구조는 실제 주문이 아닌 수강 정보와 직접 연결되어 있는 결제 시스템으로 주문N:결제1 과 유사한 구조를 가지고 있다. 결국 논리적인 버그 때문에 위와 같은 시나리오에서 해당 주문에 대한 수강 처리 결과가 오류를 보이게 되고 같은 주문에 대해 입금 되지 않을 거래 정보를 삭제하는 절차를 포함하고 있는 우리 시스템에서 변경되지 않은 주문에 대한 거래 정보를 삭제하는 버그도 포함하고 있다.
CTO 님과 이야기를 나누고 수강 정보와 결제 정보를 매핑하는 테이블을 하나 더 두기로 했다.
(물론 주문과 결제 프로세스를 분리하는 과정에서 해결할수도 있다.)
