Test Email Change Flows Without Missed Links
Menukar emel akaun kelihatan remeh. Ia adalah perangkap biasa bagi pasukan QA. Seorang penguji mengemas kini alamat. Orang lain pula membuka emel tersebut terlebih dahulu. Kini, pasukan mula bertelingkah sama ada halaman React itu rosak atau jika pautan tersebut milik pengguna yang salah.
Kekeliruan ini berlaku apabila anda menganggap peti masuk sebagai alat kongsi dan bukannya sebahagian daripada ciri tersebut.
Perjalanan pertukaran emel adalah rapuh. Ia mengubah akaun yang aktif. Anda berurusan dengan pengguna yang telah disahkan dan keadaan tertunda (pending states).
Masalah biasa termasuk:
- Mesej sampai ke peti masuk kongsi tanpa pemilik yang jelas.
- Pautan berfungsi, tetapi UI memaparkan data lama.
- Backend dikemas kini, tetapi cache frontend kekal lapuk.
- Penguji mengklik pautan yang sepatutnya untuk penguji lain.
Untuk mengatasi masalah ini, gunakan emel sementara (burner email) bagi setiap sesi ujian. Jangan gunakan satu alias staging sahaja.
Ikuti urutan ini:
- Cipta pengguna ujian melalui aplikasi.
- Mohon pertukaran emel dalam tetapan React.
- Hantar emel melalui backend sebenar.
- Hala mesej ke peti masuk sekali guna (one-run inbox).
- Buka pautan dan sahkan skrin tetapan memaparkan alamat baharu.
Pengasingan memastikan pemilikan kekal jelas. Anda tidak perlu nota yang berserabut di Slack untuk mengingati peti masuk mana yang telah digunakan.
Peraturan untuk aplikasi React: sentiasa semak skrin selepas pembacaan data baharu. Jangan percayai keadaan klien yang optimistik (optimistic client state). Mutasi mungkin memulangkan status berjaya, tetapi muat semula halaman boleh membawa kembali nilai lama. Perkara ini berlaku lebih kerap daripada yang diakui orang ramai.
Ujian hujung-ke-hujung (end-to-end) anda mesti mengesahkan:
- Emel dihantar ke alamat tertunda yang baharu.
- Pautan merujuk kepada hos yang betul.
- Pautan mengemas kini rekod akaun.
- Alamat lama hilang selepas proses refetch.
- Penggunaan semula pautan gagal dengan selamat.
Pengesahan (assertion) frontend adalah bahagian yang paling penting. Log backend yang menyatakan kejayaan adalah sia-sia jika pengguna melihat alamat yang salah. Jika cache atau store anda lapuk, ciri tersebut dianggap rosak.
Kebolehkesanan (Traceability) juga membantu. Gunakan ID korelasi dalam log dan metadata emel anda. Ini menghubungkan permintaan dengan penghantaran dan pengesahan.
Pertimbangan imbangan (tradeoffs) yang perlu diambil kira:
- Polling peti masuk adalah lebih lambat daripada mock.
- Alamat boleh buang (disposable addresses) hanya boleh menyimpan data bukan pengeluaran (non-production).
- Persekitaran pratonton (preview environments) memerlukan peraturan pembersihan.
Jangan abaikan perkara ini. Aliran emel sering terputus pada jurang antara sistem. Di situlah mock menjadi paling lemah.