Fake email untuk uji coba: alamat aman untuk formulir pendaftaran
Kalau Anda membuat atau menguji situs web, Anda terus-menerus mengetik alamat email ke formulir. Satu hal yang tidak boleh terjadi adalah pesan uji coba masuk ke kotak surat asli orang asing. Halaman ini menunjukkan fake email mana yang dipakai untuk tiap jenis pengujian — dan kapan pesannya memang harus sampai.
Tentukan dulu apakah emailnya harus sampai
Satu pertanyaan ini menentukan semuanya, dan layak ditanyakan dengan jelas, karena jawabannya “tidak” lebih sering daripada yang orang kira.
| Yang Anda uji | Emailnya harus sampai? | Pakai |
|---|---|---|
| Validasi, penyimpanan, atau tampilan alamat | tidak | domain yang dicadangkan — lihat di bawah |
| Alur konfirmasi, secara manual | ya | kotak surat di sini |
| Alur konfirmasi, otomatis | ya, bisa dibaca kode | layanan dengan API |
| Uji beban atau volume | tidak — dan tidak boleh | selalu domain yang dicadangkan |
Kalau email tidak boleh sampai: pakai nama yang dicadangkan
Ada domain yang memang dibuat untuk ini dan dijamin tidak akan pernah dimiliki siapa pun: example.com beserta saudaranya example.net dan example.org, dicadangkan oleh RFC 2606, ditambah seluruh akhiran .test.
Alamat di domain-domain ini adalah jawaban yang tepat untuk data contoh, data awal, dan uji beban. Tidak ada yang Anda kirim bisa sampai ke manusia, karena di sana tidak ada siapa-siapa — berdasarkan kesepakatan internasional, bukan keberuntungan.
test@mycompanytest.com cukup sering ternyata domain asli milik seseorang, dan uji beban yang diarahkan ke sana tidak bisa dibedakan dari serangan. Nama yang dicadangkan gratis dan menghapus seluruh jenis kecelakaan ini.Kalau email harus sampai, secara manual
Ambil alamat di sini, jalankan alurnya, lalu baca apa yang sebenarnya dikirim aplikasi Anda — header, tautan, dan bagaimana pesan itu terlihat kalau bukan program email Anda sendiri yang menampilkannya. Dua hal yang ketahuan dengan cara ini, dan tidak ketahuan oleh penangkap email lokal:
- Pengiriman sungguhan. Pesan melewati jalur email yang nyata, jadi pengirim yang salah setel gagal di sini, bukan di produksi.
- Tampilannya di mata orang asing. Tautan yang hanya jalan di sesi Anda, gambar yang tidak pernah muncul, tautan berhenti langganan yang mengarah ke localhost — semuanya langsung terlihat.
Kalau aplikasi Anda mengirim file, perhatikan juga peringatan lampirannya: itulah peringatan yang akan dilihat pengguna Anda.
Kalau harus otomatis
Mengeruk halaman sebagai gantinya adalah tukar-menukar yang buruk, bahkan kalau berhasil: rapuh, tidak terdokumentasi, dan justru jenis lalu lintas yang akhirnya diblokir.
Menguji jalur penolakan
Kegagalan yang menarik bukanlah “alamat yang valid berfungsi”. Yang layak diuji:
- Alamat di domain tanpa rekaman MX — pengiriman gagal padahal alamatnya ditulis benar. Kode Anda sebaiknya bisa membedakan keduanya. Cek mana yang mana.
- Domain internasional, dalam bentuk Unicode maupun
xn--. Kebanyakan validator menolak satu dan menerima yang lain, dan biasanya terbalik — pengonversi. - Varian Gmail dengan titik dan plus. Kalau pengecekan keunikan Anda membandingkan teks mentah, satu orang bisa membuat akun tanpa batas. Normalkan dulu — halaman itu melakukan persis apa yang seharusnya dilakukan pengecekan Anda.
- Bagian lokal yang sangat panjang. Standar mengizinkan 64 karakter; banyak formulir diam-diam memotong di 20 dan menyimpan sesuatu yang tidak lagi menuju ke mana pun.
Yang perlu dibangun, bukan diuji
Kalau produk Anda tidak menerima alamat fake email, tolaklah dengan jelas. “Email tidak valid” untuk alamat yang sepenuhnya valid adalah kesalahan paling membingungkan di bidang ini: pengguna memeriksa ejaan, mengetik ulang, dan mendapat pesan yang sama. “Kami tidak menerima alamat fake email” memakan tempat yang sama dan mengakhiri kebingungan.