Menjaga CI tetap hijau saat aplikasi Anda memakai captcha
Form signup Anda memakai PopularCaptcha. Suite end-to-end Anda harus melakukan signup. Sekarang CI merah, dan solusi yang menggoda, yaitu mematikan captcha di build test, berarti alur yang Anda uji bukan alur yang dialami pengguna Anda.
Ada beberapa jalan keluar. Perbedaannya ada pada seberapa banyak alur nyata yang mereka uji, jadi pilih yang sesuai dengan pertanyaan yang dijawab test Anda. Berikut pilihannya, kurang lebih dari yang termurah sampai yang paling realistis.
Scarnox men-solve PopularCaptcha saat ini. Tipe captcha lain segera hadir, jadi opsi solving di bawah ini hanya untuk PopularCaptcha.
1. Test key untuk unit test dan test lokal
Banyak penyedia captcha mempublikasikan test key yang selalu lolos. Gunakan saat Anda mengontrol environment dan hanya perlu memastikan form bisa dirender dan dikirim. Test key tidak menguji verifikasi yang sesungguhnya, dan tidak membantu saat Anda menguji environment yang sudah di-deploy dengan key sungguhan.
2. Bypass untuk staging Anda sendiri
Beberapa tim menambahkan header rahasia yang diterima backend sebagai pengganti token captcha. Cara ini cepat dan gratis, tetapi itu adalah jalur kode yang hanya ada untuk test, dan hanya satu kesalahan konfigurasi dari keberadaannya di produksi. Jika Anda memakainya, batasi dengan pengecekan environment, buat secret-nya panjang dan acak, lalu uji bahwa ia ditolak di produksi.
3. Mock panggilan verifikasi
Stub request verifikasi sisi server di integration test. Ini baik untuk memeriksa logika backend Anda, misalnya apa yang terjadi saat verifikasi gagal. Namun ini tidak memberi tahu apakah frontend mengirim token dengan benar, jadi pasangkan dengan salah satu opsi lain.
4. Solve sungguhan di staging dan smoke test
Saat Anda perlu membuktikan bahwa alur nyata berjalan dari ujung ke ujung, dengan key sungguhan, widget sungguhan, dan verifikasi sungguhan, ambil token dari API solver di dalam test. Ini satu-satunya opsi yang bisa menangkap integrasi widget yang rusak.
Helper Playwright terlihat seperti ini:
// Helper test Playwright
export async function solveCaptcha(page) {
const sitekey = await page.getAttribute("[data-sitekey]", "data-sitekey");
const r = await fetch("https://api.scarnox.com/api/tasks/create", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SCARNOX_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
captcha_type: "PopularCaptchaTaskProxyless",
site_key: sitekey,
site_url: page.url(),
}),
});
const { errorId, solution, errorCode, errorDescription } = await r.json();
if (errorId !== 0) throw new Error(`${errorCode}: ${errorDescription}`);
await page.evaluate((t) => {
document.querySelectorAll('[name="h-captcha-response"],[name="g-recaptcha-response"]')
.forEach((el) => { el.value = t; });
}, solution.token);
}
Panggil helper ini tepat sebelum form dikirim di dalam test, bukan di awal test. Token kedaluwarsa dalam sekitar dua menit, dan langkah lambat sebelumnya bisa menghabiskan jendela waktu itu.
Batasi solve seminimal mungkin
Suite yang melakukan signup di setiap run bisa menghasilkan banyak solve dalam seminggu. Jaga jumlahnya tetap rendah:
- Jalankan solve sungguhan hanya di staging dan di smoke test. Gunakan opsi lain di setiap commit.
- Jalankan solve sungguhan sekali per pipeline, bukan sekali per file test.
- Batasi jumlah solve per run di helper Anda. Test yang gagal karena batas tercapai adalah sinyal jelas untuk meninjau suite.
- Solve yang gagal tidak ditagih, jadi langkah yang tidak stabil membuang waktu, bukan uang. Tetapi suite yang mencoba ulang secara membabi buta tetap membuang menit runner.
Untuk aturan retry di dalam helper, gunakan kebijakan dari penanganan error dan backoff.
Jaga key tetap di luar repo
Simpan key sebagai secret CI, dengan nama seperti SCARNOX_KEY, dan jangan pernah menaruhnya di kode test atau fixture. Jika bocor, buat ulang dari dashboard. Key lama langsung berhenti berfungsi, sehingga key yang bocor tidak bisa dipakai untuk menjalankan solve dalam waktu lama.
Gunakan key terpisah untuk CI. Jika satu pipeline bermasalah, Anda bisa merotasi key itu tanpa menyentuh yang lain.
Coba di staging Anda sendiri
Buat akun dan mulai dengan kredit uji coba gratis, tanpa kartu. Pasang helper ke satu smoke test dulu, pastikan signup-nya berjalan dengan bersih, baru tambahkan ke sisa suite. Untuk biaya solving dalam volume besar, lihat harga terkini.
Yang di-assert setelah submit
Captcha yang berhasil di-solve hanya membuktikan langkah widget berhasil. Setelah submit, assert hal-hal yang penting bagi pengguna: halaman berikutnya termuat, pesan sukses muncul, dan akun atau pesanan ada di database Anda. Test yang berhenti di "tidak ada error di form" bisa lulus sementara signup diam-diam gagal di backend.
Jaga assert tetap dekat dengan hasil bisnisnya. Periksa URL, pesan yang terlihat, dan satu record yang dibuat test. Bersihkan record itu di akhir run agar run berikutnya mulai dari state yang diketahui.
Menjalankan smoke test sesuai jadwal
Jalankan smoke test solve sungguhan sesuai jadwal, misalnya sekali sehari terhadap staging, alih-alih di setiap pull request. Run terjadwal menangkap perubahan yang dilakukan situs semalam, seperti versi widget baru atau sitekey yang berpindah, tanpa menghabiskan solve di setiap commit. Beri tahu tim saat run terjadwal gagal, dan biarkan suite per commit memakai opsi yang lebih cepat.