PG 정합성 테스트

Об этом предложении

앞 글 에서 확정 실패와 결과 모름을 나눈 설계 변경을 정리했다. 이 글은 그 변경이 실제로 코드에서 지켜지는지, before(69bafa4) 시점과 after(1df9e7e) 시점의 예외 분류를 같은 시나리오로 돌려 확인한 기록이다. 재현하려는 네트워크 실패는 크게 네 가지다. Connect timeout: TCP 연결을 정해진 시간 안에 맺지 못함 Connection refused: 대상 포트가 즉시 연결을 거부 (서버가 죽은 경우) Connection reset: 연결 중에 상대나 중간 장비가 강제로 종료 Read timeout: 요청은 갔지만 응답을 기다리다 제한 시간 초과 이 중 1번(Connect timeout)은 로컬 재현이 까다롭다. SYN 패킷이 사라져야 하는데, 이걸 만들려면 방화벽으로 drop하거나 라우팅 불가 IP를 쓰는 방법뿐이다. OS마다 방화벽 조작 방식이 다르고, CI 환경에서는 이런 조작이 막혀 있어 이식성이 떨어진다. 2번(Connection refused)은 애초에 "타임아웃"이 아니라 즉시 응답이 오는 경우라, 여기서는 관심사가 아니다. 실제로 결제 호출에서 자주 마주치고 우리 코드의 예외 매핑을 검증해야 하는 경우는 3번(Connection reset)과 4번(Read timeout)이다. 이 둘만 MockRestServiceServer로 예외를 직접 주입해 검증했다. 도구는 세가지 중에서 MockRestServiceServer를 골랐다. 이번 검증 대상은 네트워크 오류가 어떤 예외 타입으로 분류되는가이고, 실제 TCP 계층에서 정말 그 예외가 튀어나오는지까지는 이번 범위가 아니다. MockRestServiceServer는 원하는 예외를 직접 주입할 수 있어 이 목적에 정확히 맞고, 별도 인프라 없이 빠르게 결정적으로 돈다. WireMock은 실제 지연과 소켓 종료를 흉내 낼 수 있고, Toxiproxy는 더 현실적인 네트워크 문제를 주입할 수 있지만, 지금 확인하려는 "예외 분류 정책"에는 오버스펙이다. before 시점(69bafa4). Read timeout, Connection reset, 500, 미등록 에러 코드가 모두 PgApproveException으로 매핑된다. 이 예외는 ChargeFacade에서 failCharge()로 이어져 충전이 FAILED로 확정된다. before 시점의 TossPaymentsClient는 생성자 안에서 RestClient를 직접 생성해 목 서버를 끼워 넣기 어려웠다. 당시 코드를 그대로 검증하기 위해 리플렉션으로 RestClient 필드를 교체했다. after 시점(1df9e7e). 같은 네트워크 오류들이 PgUnknownResultException으로 매핑된다. 충전은 IN_PROGRESS로 남고, 재조정 배치가 PG에 조회해 최종 상태로 수렴한다. 시나리오 before 예외 before 결과 after 예외 after 결과 Read timeout PgApproveException FAILED 확정 PgUnknownResultException IN_PROGRESS Connection reset PgApproveException FAILED 확정 PgUnknownResultException IN_PROGRESS 500 서버 오류 PgApproveException FAILED 확정 PgUnknownResultException IN_PROGRESS 미등록 에러 코드 PgApproveException FAILED 확정 PgUnknownResultException IN_PROGRESS 403 REJECT_CARD_PAYMENT PgApproveException FAILED 확정 PgApproveException FAILED 확정

Детали предложения

Провайдер

velog

Источник

velog-rss

Балл

54.39

Уверенность

49%