Uji Aliran Pertukaran Emel Dalam React Tanpa Terkeliru Pautan
Menukar emel akaun kelihatan remeh. Sebenarnya, ia merupakan punca utama ralat pengujian.
Penguji sering terkeliru dengan pautan pengesahan. Seorang individu mengemas kini alamat manakala orang lain membuka mesej tersebut terlebih dahulu. Ini menimbulkan kekeliruan. Pasukan mula berdebat sama ada halaman React rosak atau pautan tersebut milik pengguna yang salah.
Masalah ini berlaku kerana pasukan menganggap peti masuk sebagai alat perkongsian. Anda mesti menganggap peti masuk sebagai sebahagian daripada kontrak ciri tersebut.
Perjalanan pertukaran emel adalah rapuh. Ia mengubah akaun yang aktif. Pengguna sudah pun log masuk. Sering berlaku persaingan (race condition) antara status emel yang sedang menunggu dan emel yang telah disahkan.
Masalah biasa termasuk:
- Mesej pengesahan tiba di peti masuk kongsi tanpa cara untuk menjejaknya.
- UI memaparkan data lama walaupun pautan telah mengesahkan permintaan baharu.
- Backend dikemas kini, tetapi cache frontend memaparkan alamat lama.
- Seorang penguji mengklik pautan yang sepatutnya untuk orang lain.
Peti mel kongsi menyukarkan pencarian punca pepijat. Gunakan alamat emel "burner" yang unik untuk setiap sesi ujian berbanding menggunakan satu alias staging sahaja.
Ikuti urutan bersih ini:
- Cipta pengguna ujian.
- Mohon pertukaran emel dalam skrin tetapan React.
- Hantar emel melalui laluan backend yang sebenar.
- Hala mesej ke peti masuk yang hanya milik ujian ini.
- Buka pautan dan sahkan skrin tetapan dikemas kini dengan alamat baharu.
Ini memastikan pemilikan adalah jelas. Anda akan tahu pautan mana yang datang daripada pengguna mana.
Untuk aplikasi React, ikut satu peraturan tambahan. Lakukan pengesahan (assert) pada skrin hanya selepas pembacaan data baharu. Jangan percayai keadaan klien yang optimistik (optimistic client state). Satu mutasi mungkin memulangkan status berjaya, tetapi muat semula halaman boleh membawa kembali nilai lama jika backend tidak memuktamadkan pertukaran tersebut.
Ujian hujung-ke-hujung (end-to-end) yang baik mesti mengesahkan perkara berikut:
- Emel dihantar ke alamat yang sedang menunggu dan bukan alamat lama.
- Pautan menghala ke hos persekitaran yang betul.
- Pautan mengemas kini rekod akaun.
- Alamat lama hilang selepas proses
refetch. - Penggunaan semula pautan yang sama gagal dengan selamat.
Jika cache React query atau stor klien anda lapuk, ciri tersebut akan terasa rosak. Pelanggan hanya peduli jika skrin tetapan memaparkan realiti.
Anda juga harus menambah ID korelasi (correlation ID) pada setiap permintaan. Ini membantu anda menjejaki permintaan daripada pengguna kepada penghantaran mesej dan pengesahan akhir.
Peti masuk yang terasing tidak menggantikan ujian unit. Gunakan ujian unit untuk pengesahan borang dan ralat API. Gunakan aliran peti masuk untuk membuktikan laluan pelanggan sebenar berfungsi merentasi semua sistem.
Sebelum anda menghantar perubahan kepada tetapan akaun, semak perkara berikut:
- Mohon pertukaran daripada UI React yang sebenar.
- Sahkan mesej masuk ke peti masuk khusus untuk sesi ujian tersebut.
- Sahkan alamat baharu dipaparkan selepas
refetch. - Pastikan pautan lama tidak boleh digunakan semula.
- Sahkan log audit menunjukkan siapa yang memulakan pertukaran.
Ini mengelakkan pepijat di mana segalanya kelihatan baik secara berasingan tetapi gagal dalam dunia sebenar.