Surel konfirmasi adalah bagian dari alur pendaftaran yang tidak bisa dijalankan sendiri oleh pengujian peramban. Harus ada yang memegang alamat, menerima pesan, dan mengembalikan kode ke pengujian. API kotak surat sementara melakukan tepat itu: rangkaian uji meminta sebuah layanan membuat kotak lewat HTTP, membaca yang datang, dan membuang kotak itu saat kasus selesai. Tidak ada peramban, tidak ada kotak bersama antarorang, dan tidak ada salin tempel manual.
Artikel ini membahas sisi API dari rangkaian itu. Ini bukan tentang mengarahkan aplikasi ke titik akhir penerimaan lokal; itu adalah cara menangkap surel di CI, dan keduanya memecahkan masalah yang berbeda. Penangkapan lokal membuktikan apa yang dikirim aplikasi Anda. API kotak surat membuktikan apa yang benar-benar tiba, lewat jalur pengiriman nyata, di alamat yang dikuasai pengujian.
Mengapa memakai API kotak surat dalam pengujian?
Karena pilihannya adalah kotak manusia sungguhan atau tidak sama sekali.
Kotak bersama adalah fixture yang buruk. Beberapa proses menjalankan pembacaan pada kotak yang sama, pesan dari proses sebelumnya masih tersisa, dan alamat itu menumpuk lalu lintas yang tidak diminta pengujian mana pun. Setiap asersi lalu harus menebak pesan mana milik kasus saat ini, dan dari tebakan itulah ketidakstabilan lahir.
Memanen antarmuka web penyedia dengan peramban adalah pilihan buruk kedua. Itu membuat pengujian bergantung pada markup yang berubah tanpa pemberitahuan, pada status sesi, dan pada proses masuk yang harus diawasi rangkaian uji. Begitu penyedia mengubah gaya tombol, rangkaian hijau menjadi merah karena alasan yang tidak berhubungan dengan produk.
API kotak surat menyingkirkan kedua masalah. Alamat dibuat untuk kasus itu, kosong secara bawaan, dan dibaca lewat antarmuka stabil yang bisa dipanggil langsung oleh pengujian. Rangkaian uji tidak lagi peduli bagaimana penyedia tampak, hanya peduli kontraknya terpenuhi: buat, terima, baca, hapus.
Ada pula alasan privasi. Alamat yang dibuat lewat API tidak mewakili siapa pun. Itu bukan kotak pribadi, bukan tempat surel nyata bisa mendarat, dan dibuang bersama proses.
Endpoint apa yang benar-benar dibutuhkan sebuah pengujian?
API kotak surat bisa menyediakan puluhan rute, tetapi klien pengujian butuh empat operasi, dan akan membantu menamainya sesuai cara rangkaian uji memakainya.
Buat mengembalikan alamat dan sebuah handle. Alamat adalah yang diberitahukan ke aplikasi yang diuji sebagai tujuan pengiriman. Handle, biasanya token atau pengenal, adalah yang dipakai pengujian untuk menanyakan kotak itu pada setiap panggilan berikutnya. Rangkaian uji harus memperlakukan keduanya sebagai satu objek dan jangan pernah merekonstruksi handle dari alamat, karena penyedia bebas membuat keduanya tak berhubungan.
Daftar mengembalikan ringkasan, bukan isi: satu entri per pesan, dengan pengenal, pengirim, subjek, dan waktu tiba. Ini panggilan yang harus dipakai gelung penjajakan, karena murah dan cukup untuk menjawab satu pertanyaan yang penting di awal: apakah sudah ada yang tiba.
Baca mengembalikan satu pesan secara utuh, termasuk bagian teks dan HTML. Kode ada di sini, dan panggilan ini hanya boleh dilakukan setelah daftar melaporkan kecocokan.
Bersihkan menghapus pesan dari kotak atau menghapus seluruh kotak. Pengujian memerlukannya karena dua alasan: mengulang antarpercobaan tanpa membuat alamat baru, dan membersihkan saat kasus berakhir.
Sebagian layanan menambahkan endpoint tunggu atau jajak panjang, yang menahan koneksi sampai pesan tiba atau batas waktu habis. Itu nyaman, tetapi klien tetap harus bisa kembali ke daftar, karena panggilan tunggu adalah bagian yang paling mungkin terkena batas laju.
Bagaimana menjajak kode tanpa ketidakstabilan?
Kesalahan paling umum dalam pengujian semacam ini adalah jeda tetap. Jumlah detik yang tetap adalah tebakan: terlalu pendek saat pengiriman lambat, boros saat cepat, dan salah di kedua arah pada mesin CI yang sibuk. Ganti dengan gelung yang memanggil daftar, memeriksa kecocokan, dan kembali begitu ditemukan, dengan batas atas yang membuat pengujian gagal alih-alih menggantung tugas.
Pencocokan adalah separuh masalah lainnya. Pesan yang diinginkan pengujian adalah yang ditujukan ke alamat yang dibuat kasus itu dan, jika kotak bisa memuat lebih dari satu jenis surel, yang subjeknya membawa fragmen stabil. Pilih kecocokan terbaru, agar pengiriman ganda dari percobaan ulang tidak mengacaukan pembacaan. Jangan pernah mengambil pesan pertama tanpa syarat; pada alamat yang dipakai ulang, itulah tepatnya cara kode lama ikut tervalidasi.
Ekstraksi harus punya jangkar. Isi pesan bisa memuat nomor rujukan, stempel waktu, dan harga, dan parser yang menyambar deret angka pertama kadang menyambar salah satunya, bukan kode. Cari kata yang memperkenalkan kode, baca kode di sekitarnya, dan saat tak ada yang cocok, gagalkan dengan isi pesan dilampirkan.
Terakhir, hormati batas pengiriman ulang. Alur kode biasanya hanya mengizinkan beberapa pengiriman dalam jendela singkat, dan batas itu bagian dari perilaku yang diuji. Pengujian yang menekan tombol lagi untuk mendapat kode baru akan akhirnya ditolak dan gagal karena alasan yang salah. Coba ulang dengan membaca kotak lagi, bukan dengan memicu pesan lain.
Bagaimana menyambungkannya ke rangkaian uji ujung ke ujung atau CI?
Bentuk yang bersih adalah fixture. Sebelum alur dimulai, fixture membuat kotak dan mengembalikan alamatnya. Pengujian menjalankan aplikasi memakai alamat itu. Setelah aplikasi memastikan telah mengirim sesuatu, asersi membaca kotak dan mengekstrak kode. Saat kasus berakhir, fixture menghapus kotak.
Jaga klien tetap kecil dan bisa disuntikkan. Satu modul membungkus empat panggilan; pengujian bergantung pada modul itu, bukan pada HTTP mentah yang tersebar di rangkaian uji. Itu memungkinkan penggantian dengan tiruan pada uji unit dan mengarahkan rangkaian yang sama ke penyedia lain tanpa menulis ulang asersi.
Di CI, kredensial ditaruh di penyimpanan rahasia tugas, jangan pernah di repositori dan jangan pernah di baris log. Beri setiap tugas atau setiap pekerja paralel kotaknya sendiri, dan awali alamat yang dihasilkan dengan penanda yang mengidentifikasi proses, agar pesan tersesat bisa diatribusikan dengan pengamatan. Atur batas waktu klien di bawah batas waktu tugas itu sendiri, agar penjajakan yang macet gagal dengan pesan jelas alih-alih pembatalan tugas yang mendadak.
Coba ulang pembacaannya, bukan seluruh alur. Jika kode belum tiba, tunggu lalu baca lagi; menjalankan ulang pendaftaran akan menghasilkan pesan kedua dan, bersamanya, kandidat kedua untuk asersi. Dan jauhkan API kotak surat dari alur produksi: itu infrastruktur pengujian, dan rangkaian uji tidak boleh bisa mengirim ke pelanggan nyata darinya.
Alur di sekitar kode, bukan mekanika membacanya, dibahas di pengujian alur verifikasi surel, dan langkah parsingnya khusus dibahas di OTP dalam uji ujung ke ujung.
Isolasi dan pembersihan
Satu alamat per kasus adalah aturan yang mencegah sebagian besar kegagalan antarpengujian. Itu menghapus kebutuhan menalar pesan mana milik siapa dan membuat soal kesegaran lenyap, karena kotak itu sepanjang waktu hanya menerima lalu lintas satu kasus.
Pembersihan harus eksplisit dan tanpa syarat. Hapus kotak di teardown yang berjalan baik kasus lulus maupun gagal, bukan hanya di jalur bahagia. Mengandalkan masa hidup penyedia saja adalah kesalahan: pesan bisa bertahan cukup lama untuk dibaca proses berikutnya di mesin yang sama, dan masa hidup itu kemudahan, bukan jaminan.
Jika pembersihan gagal, catat dan biarkan rangkaian uji selesai. Galat pembersihan layak diketahui, tetapi tidak sama dengan cacat produk, dan menggagalkan proses karenanya mengajari tim mengabaikan kegagalan teardown. Perlakukan semua yang diterima alamat sebagai data uji: ia ada untuk satu asersi, tidak boleh diekspor atau dibagikan, dan tidak boleh diperlakukan sebagai titik kontak siapa pun.
Batasan dan peringatan
API kotak surat tetap ketergantungan pihak ketiga, dan batasnya menjadi batas Anda. Batas laju per menit bisa menolak ledakan pembuatan dari proses paralel besar. Kuota membatasi berapa alamat yang ada sekaligus. Pesan bisa tertunda, dan pesan tertunda terlihat persis seperti pesan hilang sampai tiba.
Domain sekali pakai juga banyak diblokir. Domain penyedia bisa ditolak oleh formulir pendaftaran yang sedang Anda uji, yang mengubah pengujian sah menjadi kegagalan yang membingungkan. Saat itu terjadi, jawabannya bukan membuat pengecualian untuk penyedia, melainkan memahami apakah produk yang diuji memang sengaja menolak alamat sekali pakai, lalu menguji perilaku itu dengan sengaja.
Ringkasan jujurnya: API kotak surat adalah alat yang tepat untuk mengklaim apa yang tiba. Untuk mengklaim apa yang dipancarkan aplikasi Anda, titik akhir penerimaan lokal lebih cepat dan tanpa kuota. Kebanyakan rangkaian uji matang memakai keduanya: penangkapan lokal untuk sebagian besar asersi, dan API kotak surat hanya saat jalur pengiriman nyata itulah yang diuji.
Langkah berikutnya
Temukan pengujian pembaca kode yang menjajak kotak bersama dan ganti dengan fixture yang membuat alamat baru dari API kotak surat. Catat alamat itu bersama proses berjalan, hapus di teardown, dan lihat berapa banyak ketidakstabilan yang selama ini Anda toleransi langsung berhenti. Saat perlu kotak nyata secara manual, halaman surel sementara membuatnya seketika, dan alamat yang diberikannya adalah perancah untuk satu proses, bukan identitas nyata.