Fałszywy adres e-mail do testów: bezpieczne adresy dla formularzy rejestracji
Jeśli tworzysz albo testujesz strony, ciągle wpisujesz adresy e-mail do formularzy. Jedno nie może się zdarzyć nigdy: testowa wiadomość nie może trafić do prawdziwej skrzynki obcej osoby. Ta strona pokazuje, jakiego fałszywego adresu e-mail użyć do każdego rodzaju testu — i kiedy wiadomość musi naprawdę dojść.
Najpierw zdecyduj, czy poczta ma dojść
To jedno pytanie rozstrzyga wszystko i warto zadać je wprost, bo odpowiedź brzmi „nie” częściej, niż się wydaje.
| Co testujesz | Czy poczta musi dojść? | Użyj |
|---|---|---|
| Walidację, zapis lub wyświetlanie adresu | nie | domeny zarezerwowanej — patrz niżej |
| Proces potwierdzania, ręcznie | tak | skrzynki stąd |
| Proces potwierdzania, automatycznie | tak, czytelnie dla kodu | usługi z API |
| Testy obciążeniowe lub wolumenowe | nie — i nie wolno | zawsze domeny zarezerwowanej |
Gdy poczta nie może dojść: nazwy zarezerwowane
Istnieją domeny stworzone dokładnie do tego, które z gwarancją nigdy do nikogo nie będą należeć: example.com i jego rodzeństwo example.net oraz example.org, zarezerwowane przez RFC 2606, a do tego cała końcówka .test.
Adresy w tych domenach to właściwa odpowiedź dla danych przykładowych, danych startowych i testów obciążeniowych. Nic, co wyślesz, nie trafi do człowieka, bo nikogo tam nie ma — na mocy międzynarodowego porozumienia, a nie szczęścia.
test@mycompanytest.com wystarczająco często okazuje się czyjąś prawdziwą domeną, a test obciążeniowy skierowany w nią nie różni się od ataku. Nazwy zarezerwowane nic nie kosztują i usuwają całą tę kategorię wypadków.Gdy poczta musi dojść, ręcznie
Weź adres stąd, przejdź proces i przeczytaj, co Twoja aplikacja naprawdę wysłała — nagłówki, linki i to, jak wiadomość wygląda, gdy nie pokazuje jej Twój własny program pocztowy. Dwie rzeczy, które tak wychwycisz, a lokalny łapacz poczty nie:
- Prawdziwe doręczenie. Wiadomość idzie prawdziwą drogą pocztową, więc źle skonfigurowany nadawca wyłoży się tutaj, a nie na produkcji.
- Jak widzi ją obcy. Linki działające tylko w Twojej sesji, obrazki, które nigdy się nie wczytują, link do wypisania wskazujący na localhost — wszystko widać od razu.
Jeśli Twoja aplikacja wysyła pliki, zwróć też uwagę na ostrzeżenia o załącznikach: to te same ostrzeżenia, które zobaczą Twoi użytkownicy.
Gdy musi to być automatyczne
Wyciąganie danych ze strony zamiast tego to zły interes, nawet gdy działa: jest kruche, nieudokumentowane i to dokładnie taki ruch, który w końcu zostaje zablokowany.
Testowanie ścieżek odrzucenia
Ciekawe błędy to nie „poprawny adres działa”. Warto pokryć:
- Adres w domenie bez rekordu MX — doręczenie się nie udaje, choć adres jest poprawnie zapisany. Twój kod powinien odróżniać jedno od drugiego. Sprawdź, co jest czym.
- Domenę międzynarodową — zarówno w Unicode, jak i w postaci
xn--. Większość walidatorów odrzuca jedną i przyjmuje drugą, zwykle odwrotnie, niż powinna — konwerter. - Warianty Gmaila z kropkami i plusem. Jeśli Twoja kontrola unikalności porównuje surowe ciągi znaków, jedna osoba może założyć dowolnie wiele kont. Najpierw znormalizuj — ta strona robi dokładnie to, co powinna robić Twoja kontrola.
- Bardzo długą część lokalną. Standard dopuszcza 64 znaki; wiele formularzy po cichu ucina na 20 i zapisuje coś, co już nigdzie nie prowadzi.
Coś do zbudowania, nie do testowania
Jeśli Twój produkt nie przyjmuje fałszywych adresów e-mail, odrzucaj je jasno. „Nieprawidłowy e-mail” dla całkowicie poprawnego adresu to najbardziej mylący błąd w tej kategorii: użytkownik sprawdza pisownię, wpisuje ponownie i dostaje ten sam komunikat. „Nie przyjmujemy fałszywych adresów e-mail” zajmuje tyle samo miejsca i kończy zamieszanie.