React에서 링크가 섞이지 않게 이메일 변경 흐름을 테스트하는 방법
계정 이메일을 변경하는 것은 사소해 보일 수 있지만, 실제로는 테스트 오류가 빈번하게 발생하는 주요 원인입니다.
테스터들은 종종 확인 링크를 혼동합니다. 한 사람이 주소를 업데이트하는 동안 다른 사람이 먼저 메시지를 열어버리기도 합니다. 이는 혼란을 야기합니다. 팀은 React 페이지가 고장 난 것인지, 아니면 링크가 잘못된 사용자의 것인지 논쟁하기 시작합니다.
이 문제는 팀이 편지함을 공유 도구로 취급하기 때문에 발생합니다. 편지함을 기능 계약(feature contract)의 일부로 간주해야 합니다.
이메일 변경 과정은 취약합니다. 활성 계정을 변경하는 작업이며, 사용자는 이미 로그인된 상태이기 때문입니다. 대기 중인 이메일 상태와 확인된 이메일 상태 사이에 레이스 컨디션(race condition)이 자주 발생합니다.
일반적인 문제로는 다음과 같은 것들이 있습니다:
- 확인 메시지가 추적할 방법이 없는 공유 편지함으로 도착함.
- 링크를 통해 새 요청이 확인된 후에도 UI에 이전 데이터가 표시됨.
- 백엔드는 업데이트되었지만, 프론트엔드 캐시에는 이전 주소가 표시됨.
- 한 테스터가 다른 사람을 위한 링크를 클릭함.
공유 메일함은 버그의 원인을 파악하기 어렵게 만듭니다. 단일 스테이징 별칭(alias) 대신 매 테스트 실행마다 고유한 일회용(burner) 이메일 주소를 사용하세요.
다음과 같은 깔끔한 순서를 따르십시오:
- 테스트 사용자를 생성합니다.
- React 설정 화면에서 이메일 변경을 요청합니다.
- 실제 백엔드 경로를 통해 메일을 보냅니다.
- 해당 테스트에만 속하는 편지함으로 메시지를 라우팅합니다.
- 링크를 열고 설정 화면이 새 주소로 새로고침되는지 확인합니다.
이렇게 하면 소유권이 명확해집니다. 어떤 링크가 어떤 사용자로부터 왔는지 알 수 있습니다.
React 앱의 경우, 한 가지 규칙을 더 추가하십시오. 데이터를 새로 읽어온 후에만 화면을 검증(assert)해야 합니다. 낙관적 클라이언트 상태(optimistic client state)를 신뢰하지 마세요. 뮤테이션(mutation)이 성공을 반환하더라도, 백엔드에서 변경 사항을 확정하지 않았다면 페이지를 새로고침했을 때 이전 값이 다시 나타날 수 있습니다.
좋은 엔드 투 엔드(E2E) 테스트는 다음 사항들을 검증해야 합니다:
- 이메일이 이전 주소가 아닌 대기 중인 주소로 전송되었는지 여부.
- 링크가 올바른 환경의 호스트를 가리키는지 여부.
- 링크가 계정 레코드를 업데이트하는지 여부.
- 리페치(refetch) 후 이전 주소가 사라지는지 여부.
- 동일한 링크를 재사용할 때 안전하게 실패하는지 여부.
React 쿼리 캐시나 클라이언트 스토어가 오래된 상태(stale)라면, 기능이 고장 난 것처럼 느껴집니다. 고객은 설정 화면이 실제 상태를 정확히 보여주는지에만 관심이 있습니다.
또한 각 요청에 상관관계 ID(correlation ID)를 추가해야 합니다. 이는 사용자로부터 메시지 전달 및 최종 확인에 이르기까지 요청을 추적하는 데 도움이 됩니다.
격리된 편지함이 유닛 테스트를 대체할 수는 없습니다. 폼 유효성 검사 및 API 오류에는 유닛 테스트를 사용하세요. 편지함 흐름은 모든 시스템에서 실제 고객 경로가 정상적으로 작동함을 증명하는 데 사용하십시오.
계정 설정 변경 사항을 배포하기 전에 다음 항목을 확인하십시오:
- 실제 React UI에서 변경을 요청합니다.
- 메시지가 해당 실행에 특화된 편지함에 도착하는지 확인합니다.
- 리페치 후 새 주소가 표시되는지 확인합니다.
- 이전 링크를 재사용할 수 없는지 확인합니다.
- 감사 로그(audit logs)에 누가 변경을 시작했는지 확인합니다.
이는 개별적으로는 문제가 없어 보이지만 실제 환경에서는 실패하는 버그를 방지합니다.