Jika pengujian email Anda berjalan sempurna di laptop tetapi hancur saat mencapai CI, Anda tidak sendirian. Respons yang biasanya dilakukan adalah menyisipkan panggilan sleep di seluruh kode pengujian atau menaikkan jumlah percobaan (retry) hingga build berhasil. Hal itu mungkin meredam gangguan untuk sementara, tetapi tidak memperbaiki bug tersebut. Itu hanya menyembunyikannya.
Masalah sebenarnya adalah bagaimana pengujian Anda mengidentifikasi email mana yang harus dibuka.
Masalah Shared Inbox
Di mesin lokal, Anda menjalankan satu pengujian dalam satu waktu. Satu email masuk. Anda mengambilnya. Sederhana.
CI adalah lingkungan yang sepenuhnya berbeda. Satu pull request mungkin memicu empat, delapan, atau enam belas pekerjaan (job) paralel. Jika semuanya berbagi satu inbox pengujian—baik itu server Mailosaur, inbox Mailtrap, atau akun asli pada domain staging—semuanya menulis ke bucket yang sama pada saat yang bersamaan. Job A mengirim reset kata sandi. Job B mengirim undangan. Job C mencoba kembali alur selamat datang yang gagal. Sementara itu, background worker dan antrean pengiriman menambah jitter yang tidak dapat Anda kendalikan.
Ketika setiap job mengakses shared inbox tersebut dan meminta pesan terbaru dengan subjek "Reset your password", hal ini menjadi sebuah perlombaan (race). Pengujian yang menang mendapatkan email yang benar. Pengujian yang kalah mengklik tautan yang ditujukan untuk job lain, melakukan asersi terhadap konten yang salah, dan gagal dengan error yang tampak seperti masalah waktu (timing). Ini bukan masalah waktu. Ini adalah masalah identitas.
Mengapa "Pesan Terbaru" Gagal
Pola yang rapuh ini mudah diikuti karena terasa intuitif:
- Memicu alur pengguna.
- Melakukan polling pada inbox setiap beberapa detik.
- Membuka pesan terbaru yang sesuai dengan baris subjek.
Secara praktis, helper Anda sebaiknya mencari Subject:"Welcome to AppName" AND Body:"a4f9c2d1" daripada Subject:"Welcome to AppName" sort:-received. Banyak layanan pengujian email menyediakan API pencarian yang menerima filter konten body. Gunakanlah. Jika Anda bekerja dengan penyedia yang lebih sederhana, simpan logika polling Anda di satu tempat agar Anda dapat menambahkan filter sisi klien secara konsisten di setiap pengujian.
Tiga Aturan untuk Menjaga Kejujuran Sistem
Sebuah run token memastikan pemilihan yang tepat, tetapi Anda tetap membutuhkan disiplin dalam cara Anda melakukan polling dan apa yang Anda lakukan saat terjadi kesalahan.
Catat status inbox saat terjadi kegagalan. Ketika pengujian gagal, tampilkan pengenal inbox, baris subjek yang Anda cari, jendela timestamp yang tepat, dan berapa banyak pesan yang sesuai dengan kriteria Anda. Ini mengubah kesalahan "email tidak ditemukan" yang samar menjadi sebuah cerita yang konkret. Jika job 7823 mengambil pesan retry dari job 7821 karena pesan tersebut tiba tiga detik kemudian, log Anda harus menunjukkannya dengan jelas. Tanpa konteks ini, Anda akan menyalahkan masalah timing dan menambahkan sleep lainnya.
Simpan semua email polling dalam satu file helper. Jangan menyebarkan panggilan setTimeout dan cy.task di dua puluh file pengujian. Sentralisasikan logika yang menunggu pesan, mencoba kembali (retry) panggilan API, dan menerapkan backoff. Jika setiap pengujian menggunakan helper yang sama, aturan penyaringan Anda akan tetap konsisten, dan saat Anda meningkatkan logika pencarian, setiap pengujian akan mendapatkan manfaatnya. Ini juga memudahkan penerapan pemeriksaan token; jika helper memerlukan argumen token, tidak ada yang bisa secara tidak sengaja kembali menggunakan metode "pesan terbaru" yang tidak akurat.
Perhatikan retry Anda. Retry pengujian adalah hal umum di CI, tetapi setiap retry membuat email lain di dalam inbox. Jika pengujian Anda berhasil pada percobaan ketiga, Anda mungkin akan merayakannya dan lanjut ke tahap berikutnya. Yang Anda lewatkan adalah bahwa percobaan pertama dan kedua sebenarnya mengungkap bug nyata—seperti race condition, pengiriman duplikat, atau indeks yang hilang—yang tertutupi oleh pesan tambahan tersebut. Jika Anda harus menggunakan retry, periksa apakah inbox berisi duplikat yang tidak terduga setelah kegagalan. Lebih baik lagi, pertimbangkan untuk membersihkan inbox atau menggunakan alamat unik per job jika penyedia Anda mendukung dynamic inbox. Retry tidak boleh menjadi strategi untuk menutupi logika pemilihan yang tidak andal.
Kesimpulan Utama
Mengurutkan inbox berdasarkan tanggal dan mengambil hasil teratas bukanlah pengujian. Itu hanyalah tebakan yang dibungkus dalam kode. Sebuah run token hampir tidak membutuhkan biaya—hanya satu variabel string, satu parameter filter tambahan, mungkin sedikit perubahan template—dan itu memberikan identitas deterministik pada pengujian Anda. Ini membuktikan bahwa pesan di depan Anda adalah milik run yang sedang Anda jalankan saat ini.
Berhentilah menambahkan sleep dan berharap jaringan berperilaku baik. Buatlah sebuah token, masukkan ke dalam email, dan cari secara langsung. Jalankan CI Anda akan lebih cepat, log Anda akan mudah dibaca, dan akhirnya Anda akan mempercayai apa yang disampaikan oleh suite email Anda.