Skip to content

Menulis E2E untuk Halaman yang Menunda Fetch-nya

Adityo Guni Waluyo

Spesifikasi E2E 52 baris untuk halaman daftar ber-debounce 350 ms: nol waitForTimeout, assertion retry sendiri, lima hook data-testid, dan index QA bertambah.

Ringkasan

Tes untuk halaman daftar dibuat dengan 52 baris kode. Tes ini menggunakan Playwright untuk menguji elemen berulang kali sampai kondisinya terpenuhi. Timeout assertion dinaikkan menjadi 10 detik untuk mengakomodasi jaringan yang lambat.

Spesifikasi E2E untuk halaman daftar di portal kota itu baru dibuat, 52 baris, empat test, dan satu komentar di kepala file yang bunyinya jelas: halaman menunda fetch klien sebesar 350 milidetik, jadi assertion memakai retry otomatis Playwright, bukan waitForTimeout. Commit 85c067f, +53 baris di dua file. Tidak ada satu pun sleep di dalamnya.

Refleks yang Memindahkan Balapan

Daftar itu mengambil datanya di browser, dan setiap ketikan pencarian ditahan 350 milidetik sebelum request benar-benar berangkat. Balapan antara tes dan jaringan terlihat jelas, dan cara paling cepat menutupnya adalah menidurkan tes selama setengah detik sebelum membaca hasilnya. Cara itu bekerja pada mesin yang sedang sepi, lalu berubah menjadi merah pada mesin yang sedang sibuk, karena jeda tetap dan jaringan yang tidak tetap tidak pernah cocok.

Spesifikasi ini memilih jalan lain. Playwright menguji ulang elemen berulang kali sampai kondisinya terpenuhi atau timeout tercapai [1], sehingga penundaan 350 milidetik tidak perlu muncul di dalam tes sama sekali. Timeout assertion bawaan adalah 5 detik; spesifikasi ini menaikkannya secara eksplisit menjadi 10 detik pada assertion yang menunggu data, bukan menambahkan jeda.

Keraguan yang muncul waktu itu sederhana: kalau tidak ada jeda, bagaimana tes tahu elemennya sudah ada. Jawabannya ada pada lokator. Lokator datang dengan auto waiting dan retry-ability, dan Playwright memeriksa kelayakan aksi seperti elemen terlihat dan aktif sebelum menindaklanjutinya [2]. Assertion bukan membaca DOM sekali lalu menyerah; ia membaca, menunggu, lalu membaca lagi.

Lima Hook, Empat Perilaku

Spesifikasi menancapkan lima hook lewat data-testid: kartu cabor, kolom pencarian, tab badan fungsional, blok detail, dan tabel pengurus. Testing by test id adalah cara paling tahan banting karena tes tetap hidup walau teks atau peran elemen berubah [3]. Untuk halaman daftar yang isinya kartu dengan judul yang bisa berubah kapan saja, pilihan itu terasa paling tidak rapuh.

Empat test menutup empat perilaku. Yang pertama memastikan halaman terbuka dan kartu pertama terlihat, lalu menghitung kartu dan memastikan jumlahnya lebih dari nol. Yang kedua mengisi kolom pencarian dengan ABTI, lalu memastikan tersisa tepat satu kartu dan isinya memuat teks yang sama. Yang ketiga menekan tab badan fungsional dan memastikan kartunya bertambah menjadi dua. Yang keempat menekan kartu pertama dan memastikan blok detail beserta tabel pengurus muncul.

Jumlah satu dan dua itu fakta data uji yang ditanam, bukan perilaku produk yang dijanjikan. Tes membaca fixture, dan bila fixture berubah, angkanya ikut berubah; yang dijaga adalah urutan perilakunya, bukan angkanya.

Dua detail di antaranya mudah terlewat. Test pertama tidak hanya memastikan kartu ada, tetapi juga menghitungnya dan memastikan hasilnya lebih dari nol, sehingga halaman yang terbuka tanpa isi tetap gagal meski judulnya benar. Test terakhir tidak memeriksa URL baru setelah kartu ditekan; ia memeriksa dua elemen, blok detail dan tabel pengurus, yang berarti tampilan detail memang muncul di halaman yang sama, bukan di rute terpisah yang belum tentu diuji oleh tes ini.

Anggaran, Bukan Jeda

Timeout 10 detik pada assertion adalah anggaran untuk halaman, bukan jeda untuk tes. Ia memberi ruang bagi jaringan yang lambat tanpa memperlambat tes saat halaman cepat, karena penghitungannya berhenti begitu kondisinya terpenuhi. Pola yang dipakai seluruh file ini:

test("filters the listing by search", async ({ page }) => {
  await page.goto("/informasi/olahraga");
  const cards = page.locator('[data-testid="cabor-card"]');

  await expect(cards.first()).toBeVisible({ timeout: 10_000 });

  await page.locator('[data-testid="cabor-search"]').fill("ABTI");
  await expect(cards).toHaveCount(1, { timeout: 10_000 });
});

Tidak ada baris yang menunggu waktu. Setiap penantian berubah menjadi assertion yang punya syarat: kartu terlihat, jumlahnya satu, teksnya sesuai. Kalau halaman butuh 400 milidetik, tes selesai 400 milidetik kemudian; kalau halaman butuh 6 detik, tes gagal dengan pesan yang menyebut syarat yang tidak terpenuhi, bukan dengan snapshot yang salah.

Index yang Ikut Berubah

Commit ini tidak berhenti di file spec. Indeks QA modul bertambah satu baris yang mencatat modul apa yang diuji, file spec-nya, perintah menjalankannya, dan harapan yang tertanam: fetch limit 100, debounce 350 milidetik, satu kartu untuk ABTI, dua kartu untuk tab badan fungsional, dan tabel pengurus yang muncul setelah kartu ditekan. Baris itu adalah bagian dari tes, bukan catatan tambahan. Tanpanya, orang berikutnya hanya melihat hijau tanpa tahu hijau itu berarti apa.

Keputusan yang bertahan setelah commit ini: penantian tidak dipindahkan ke dalam tes, melainkan dihapus dari pertanyaannya. Yang ditanya bukan lagi "sudah cukup lama belum", melainkan "sudah benar belum", dan pertanyaan kedua itu bisa dijawab berulang kali tanpa biaya.

Sumber:

Artikel terkait