불안정한 테스트를 구축하지 않고 임시 이메일 API를 사용하는 방법

잘못된 이유로 이메일 테스트를 통과할 수 있습니다. 공유 받은 편지함에 어제의 코드가 포함될 수 있고, 조용한 아침에 고정된 10초 절전 모드가 작동할 수 있으며, 마감 기한이 없는 재시도 루프는 애플리케이션이 실패한 후에도 오랫동안 CI 작업자를 계속 사용할 수 있습니다.

신뢰할 수 있는 임시 이메일 API 테스트는 생성, 트리거, 폴링, 일치, 어설션 및 정리를 수행하는 작은 상태 시스템입니다. 각 단계마다 명확한 소유자, 기한, 메시지 자체가 유출되지 않는 증거가 필요합니다.

흐름을 자동화하기 전에 더 광범위한 이메일 테스트 체크리스트]를 사용하여 어떤 전달, 렌더링 및 보안 동작이 테스트 스위트에 속하는지 결정하세요.

모든 테스트 실행에 자체 받은 편지함 제공

하나의 테스트 또는 밀접하게 관련된 하나의 시나리오에 대한 새 받은 편지함을 만듭니다. 병렬 작업자가 동일한 주소를 읽지 못하게 하세요. 주소뿐만 아니라 반환된 받은 편지함 식별자를 테스트 컨텍스트에 기록합니다. 후속 요청은 해당 불투명 식별자를 참조해야 합니다.

메일을 보내는 작업 직전에 받은 편지함을 만듭니다. 이는 시간 창을 좁히고 오래된 메시지가 약한 주장을 만족시키는 것을 방지합니다. 테스트 실행기가 실패한 작업을 다시 시도할 수 있는 경우 기억에 남는 이메일 주소를 선택하려고 시도하는 대신 로컬 진단 메타데이터에 해당 실행 식별자를 포함하십시오.

하나의 관찰 가능한 작업을 트리거합니다.

테스트 중인 시스템에 확인 링크 전송, 로그인 코드 전달, 영수증 발행 등 정확히 한 가지 작업을 수행하도록 요청하세요. 애플리케이션이 제공하는 요청 또는 이벤트 식별자를 캡처합니다. 해당 식별자는 제목만 일치하는 것보다 더 강력한 증거입니다.

원치 않는 타사 시스템을 테스트하지 마십시오. 자동 받은편지함은 귀하가 소유하고 있거나 평가할 권한이 있는 애플리케이션을 위한 것입니다. 이는 계정 파밍, 플랫폼 제어 우회 또는 다른 사람의 서신 모니터링을 위한 메커니즘이 아닙니다.

마감일과 백오프가 있는 폴링

메일 배달은 비동기식이므로 즉시 빈 목록이 나타나는 것이 일반적입니다. 부드럽게 투표하고 단호하게 중지하십시오. 유용한 시작 예산은 1, 2, 3, 5, 8, 10초의 대기 시간을 포함하는 60초 마감 시간입니다. 많은 작업자가 함께 시작할 때 약간의 무작위 불안감을 추가하십시오.

deadline = now + 60 seconds
delay = 1 second
while now < deadline:
    messages = list_messages(inbox_id)
    candidate = find_expected(messages)
    if candidate exists: return candidate
    sleep(delay + jitter)
    delay = min(delay * 1.6, 10 seconds)
fail("expected email did not arrive before deadline")

429 Too Many Requests 및 모든 Retry-After 값을 존중합니다. 비율 제한 이후 더 적극적으로 재시도하면 테스트가 복구될 가능성이 낮아집니다. 임시 5xx 및 네트워크 오류는 원래 기한 내에만 다시 시도하세요. 1분 테스트를 10분 테스트로 조용히 바꾸지 마십시오.

제목뿐만 아니라 거래도 일치시키세요

제목 줄은 사람을 위해 작성되었으며 변경될 수 있습니다. 증거 조합을 선호합니다.

• 작업이 시작된 후 메시지가 도착했습니다.
• 수신자는 이 실행을 위해 생성된 받은 편지함입니다.
• 발신자 도메인이 예상됩니다.
• 상관관계 식별자 또는 일회성 링크가 테스트 거래에 속합니다.
• 정확히 하나의 후보가 있거나 테스트에서 명시적으로 최신 유효한 후보를 선택합니다.

메시지 HTML을 신뢰할 수 없는 입력으로 처리합니다. 일반 검색 프로필에서 스크립트를 실행하거나, 원격 이미지를 로드하거나, 링크를 열지 마십시오. 제어된 테스트 클라이언트가 이를 따르기 전에 대상 URL을 추출하고 구문 분석한 후 등록된 대상을 어설션합니다.

테스트 출력에 비밀을 유지하세요

API 키, 인증 코드 및 매직 링크는 수명이 짧은 경우에도 자격 증명입니다. CI 비밀 저장소에 API 키를 넣고 인증 헤더로 보냅니다. 쿼리 문자열, 스크린샷, 고정 파일 또는 저장소 구성에 배치하지 마십시오.

실패 시 제한된 메타데이터(받은 편지함 식별자 접미사, 타임스탬프, 메시지 수, 수정된 보낸 사람 도메인, HTTP 상태 및 요청 ID)를 기록합니다. 헤더, 본문, 첨부 파일 또는 전체 주소를 덤핑하지 마세요. 유용한 테스트 보고서는 상태 시스템이 다른 사서함 아카이브가 되지 않고 중지된 위치를 설명합니다.

finally 블록에서 정리

삭제는 어설션의 통과 여부에 관계없이 실행되어야 합니다. 테스트 프레임워크의 finally, 분해 또는 after-each 후크에 받은 편지함 정리를 추가합니다. 정리를 통해 우발적인 보존을 줄이고 이후 테스트를 격리하며 할당량 사용량을 더 쉽게 이해할 수 있습니다.

일시적으로 삭제에 실패한 경우 제품 주장과 별도로 보고하세요. 원래의 실패를 숨기지 마십시오. 예약된 서버 측 만료는 백스톱으로서 여전히 유용하지만 의도적인 정리를 대체해서는 안 됩니다.

병렬화하기 전에 할당량 계획

시나리오별 예상 통화 수: 받은 편지함 생성 1회, 목록 요청 여러 개, 세부 정보 요청 1회, 삭제 1회. 매초 폴링하는 10명의 작업자는 전송 속도를 높이지 않고도 공유 한도를 소진할 수 있습니다. 작업자 동시성을 결합하고 테스트 프로세스 전반에 걸쳐 문서화된 요율 예산을 공유하고 계정 대시보드에 월간 소비량을 표시합니다.

Once Email의 계획된 개발자 계층은 무료 브라우저 허용과 API 자동화를 분리합니다. 인증, 오류, 할당량 및 가격 계약은 라이브 키 처리, 계량 및 구독 취소가 프로덕션 테스트를 통과한 후에 게시됩니다. 이를 통해 제품 주장이 사용자가 실제로 확인할 수 있는 기능과 일치하도록 유지됩니다.

최고의 이메일 테스트는 영원히 재시도하는 테스트가 아닙니다. 격리된 받은 편지함을 만들고, 정중하게 기다리고, 올바른 거래가 도착했음을 증명하고, 안전한 증거를 기록하고, 어떤 편지함도 남기지 않는 것입니다.