문제의 역사:
이메일 알림 테스트 자동화는 알림 시스템(예: 회원 가입, 비밀번호 변경, 알림) 개발과 함께 중요해졌습니다. 처음에는 이러한 테스트가 수동으로 수행되었고 실제 이메일을 통해 확인되었습니다(이는 CI/CD에서 매우 비효율적이고 안전하지 않습니다). 그런 다음 MailHog, Mailtrap, fake SMTP 서버와 같은 전문 도구가 등장하여 자동화를 가능하고 안전하게 만들었습니다.
문제:
주요 어려움은 이메일이 시스템 "외부"로 전송되기 때문에, 다음을 수행해야 한다는 것입니다: a) 전송을 가로채기, b) 이메일 내용 확인, c) 전송의 정확성 확인(헤더 형식, 첨부 파일 존재, 링크, i18n, 시스템 이벤트와의 적절한 연결). 배송 속도, 테스트 간의 메일함 정리, SMTP 오류 처리와 관련하여 추가적인 어려움이 있습니다.
해결책:
Mailtrap, MailHog와 같은 이메일 가로채기 특수 서비스를 사용하거나 실제 이메일로 이메일을 전송하지 않고 테스트 "바구니"에 저장하는 통합된 fake SMTP 서버를 사용할 수 있습니다.
API 프레임워크 또는 REST 래퍼를 통해 이러한 도구와 작업을 통합하고 이메일을 기다리는 기능, 이메일의 주요 매개변수 확인, 첨부 파일 검증, 올바른 링크 존재를 구현할 수 있습니다.
테스트를 위해 고유한 이메일 수신자 생성, 테스트 데이터를 분리(예: 테스트 도메인 사용)하고 각 자동 테스트 실행 전에 메일함을 정리합니다.
이메일 본문뿐만 아니라 링크의 작동 여부, 다양한 SMTP에서의 전송, 다양한 로케일 및 형식을 위한 표시 정확성을 검사합니다.
주요 특징:
일반 이메일 박스(gmail/yandex 등)로 이메일 알림을 테스트하고 IMAP을 통해 확인할 수 있나요?
아니요, 그렇게 하는 경우가 많지만 이 접근 방식은 신뢰할 수 없습니다(외부 이메일 서비스의 작동 의존성, 스팸 필터, 테스트 간 격리 부족, 메일함 정리의 어려움, 배달 보장 없음).
이메일이 도착했는지만 확인하면 충분한가요?
아니요, 본문, 첨부 파일, 필요한 링크의 존재, 올바른 언어 템플릿, 헤더(From/To/Subject)의 일치, MIME 구조의 정확성을 검증해야 합니다.
테스트 간에 fake inbox를 비워두지 않아도 괜찮은가요?
아니요! 테스트 간 inbox를 비우지 않으면 혼란이 빨리 생기고 버그를 잡기가 불가능해집니다. 시나리오는 "타인의" 이메일을 "보게" 되고 테스트가 유효하지 않게 됩니다.
이메일 테스트는 테스트 Gmail을 통해 수행되었고, IMAP을 통해 로그인하고 단순히 "무언가가 도착했다"고 확인했습니다. 이메일은 종종 스팸에 걸렸고 일부 이메일은 도달하지 않았으며, 여러 테스트를 параллельно 실행한 후 하나의 inbox에서 이메일을 분석하는 것이 불가능해졌습니다.
장점:
단점:
Mailtrap을 도입하고 각 테스트 케이스에 대해 고유한 inbox를 할당하고 자동 정리, 내용 및 첨부 파일 검증, 대기 시간, 언어별 체크를 구현했습니다.
장점:
단점: