E2E Test untuk Aplikasi Hasil Vibe Coding

Di episode kemarin kita belajar unit test, cara memastikan tiap fungsi kecil di aplikasimu berjalan benar. Tapi ada masalah yang tidak bisa ditangkap unit test: aplikasi yang setiap fungsinya benar, tapi alurnya rusak. Tombol bayar yang tidak mengarah ke mana-mana. Halaman yang blank setelah login. Data form yang hilang di tengah jalan. Episode 14 ini tentang E2E test, cara memastikan aplikasimu berjalan utuh dari sudut pandang pengguna asli.

Satu catatan jujur seperti biasa. Penjelasan soal Playwright dan Cypress di bawah ini disusun dari dokumentasi resmi dan laporan komunitas per Oktober 2026, bukan dari pengalaman pribadi bertahun-tahun. Angka dan fiturnya bisa berubah, jadi anggap ini peta, bukan vonis.

Dari Unit Test ke E2E: Apa Bedanya?

Unit test menguji satu fungsi yang terisolasi, misalnya fungsi hitung diskon mengembalikan angka yang benar. E2E (end-to-end) menguji alur lengkap seperti yang dilakukan pengguna sungguhan: membuka browser, mengetik email dan password, mengklik tombol login, menambah barang ke keranjang, lalu checkout sampai muncul halaman sukses. Kalau unit test memeriksa tiap bahan masakan satu per satu, E2E test menyajikan hidangan lengkapnya ke tamu dan memastikan semuanya bisa dimakan berurutan tanpa ada yang basi di tengah.

Perbedaan pentingnya ada di apa yang dianggap rusak. Unit test berkata "fungsi ini benar". E2E test berkata "pengguna bisa menyelesaikan tugasnya". Dua hal ini tidak sama. Fungsi login bisa 100 persen benar, tapi kalau tombol login tidak terhubung ke fungsi itu, pengguna tetap tidak bisa masuk.

Kenapa Aplikasi Hasil AI Butuh E2E Test

Aplikasi hasil vibe coding punya pola kegagalan yang khas. AI menulis kode per bagian: halaman login di satu respon, halaman keranjang di respon lain, logika checkout di respon ketiga. Tiap bagian terlihat rapi dan tiap fungsi bisa lolos unit test. Tapi AI jarang memakai aplikasinya sendiri dari awal sampai akhir seperti manusia. Akibatnya bagian yang paling sering rusak adalah sambungannya: nama route yang salah ketik, state login yang tidak terbawa ke halaman berikut, event handler yang lupa dipasang, atau data yang formatnya beda antara pengirim dan penerima.

Inilah jebakan klasik vibe coding: semua lampu hijau di level fungsi, tapi aplikasinya tidak bisa dipakai. E2E test adalah jaring pengaman untuk pola ini. Satu skenario E2E yang melewati alur kritis aplikasimu jauh lebih berharga daripada 50 unit test untuk aplikasi yang tidak bisa dibuka.

Kenalan dengan Playwright dan Cypress

Dua nama yang paling sering disebut untuk E2E test di dunia web adalah Playwright dan Cypress. Keduanya gratis dan open source, dan keduanya bekerja dengan cara yang sama secara garis besar: mereka membuka browser sungguhan, lalu menjalankan skenario klik dan ketik secara otomatis.

Playwright dibuat oleh Microsoft. Kelebihannya, satu tools bisa mengendalikan Chrome, Firefox, dan Safari sekaligus, jadi kamu bisa memastikan aplikasimu jalan di banyak browser. API-nya modern dan dokumentasinya rapi.

Cypress adalah favorit komunitas yang sudah lama. Cara menulis test-nya mudah dibaca pemula, hampir seperti membaca kalimat bahasa Inggris, dan tampilan hasil test-nya enak dilihat. Kekurangannya dibanding Playwright, dukungan multi-browser-nya tidak seluas itu.

Mana yang kamu pilih? Aturan praktisnya sederhana. Kalau prioritasmu adalah cepat paham dan cepat jalan, mulai dari Cypress. Kalau aplikasimu harus diuji di banyak browser sekaligus, pilih Playwright. Kabar baiknya, kamu tidak perlu menghafal sintaks keduanya, karena AI bisa menuliskannya untukmu. Tugasmu adalah memahami konsepnya dan bisa membaca hasilnya.

Soal biaya, keduanya punya versi open source yang gratis dan cukup untuk kebutuhan belajar sampai project kecil. Instalasi awalnya juga satu perintah. Untuk Playwright, jalankan npm init playwright@latest dan ikuti panduannya. Untuk Cypress, npm install cypress lalu buka dengan npx cypress open. Jangan habiskan waktu berhari-hari membandingkan keduanya dari artikel. Install satu, buat satu skenario, rasakan sendiri. Pengalaman satu jam memakai jauh lebih berharga daripada sepuluh jam membaca perbandingan.

Satu hal lagi soal porsi. E2E test itu lambat dan mahal dibanding unit test, karena ia menjalankan browser sungguhan. Jadi jangan menguji semua hal lewat E2E. Aturan praktisnya: unit test untuk logika, E2E test untuk alur kritis. Pilih 3 sampai 5 alur yang paling penting di aplikasimu, misalnya daftar, login, dan checkout. Alur-alur inilah yang dijaga E2E. Sisanya serahkan ke unit test yang cepat dan murah. Fokus yang sempit ini juga membuat test-mu jarang flaky, karena semakin sedikit yang diuji semakin mudah dijaga stabil.

Minta AI Menulis Skenario E2E

Menulis skenario E2E dari nol itu melelahkan, dan inilah bagian yang paling enak didelegasikan ke AI. Tapi AI butuh bahan yang lengkap supaya skenarionya tidak ngawur. Beri dia empat hal: file atau halaman yang terlibat, langkah alur yang harus diuji berurutan, data dummy untuk login dan form, dan hasil yang kamu harapkan di tiap langkah. Tanpa ini AI akan menebak struktur halamanmu, dan tebakannya hampir pasti salah.

Contohnya untuk alur login sampai checkout di toko onlinemu. Perhatikan betapa spesifiknya prompt ini soal langkah dan ekspektasi.

Buatkan E2E test dengan Playwright untuk file tests/e2e/checkout.spec.js.
Alur yang diuji:
1. Buka halaman /login, isi email "test@mail.com" dan password "rahasia123", klik tombol Login.
2. Pastikan halaman berpindah ke /produk dan nama pengguna muncul di navbar.
3. Klik tombol "Tambah" pada produk pertama, pastikan ikon keranjang menunjukkan angka 1.
4. Buka halaman /checkout, isi alamat "Jl. Mawar No. 10", klik "Bayar".
5. Pastikan muncul teks "Pesanan berhasil" dan nomor pesanan terlihat.
Batasan: gunakan data-testid untuk selector bila tersedia di kode, jangan pakai sleep dengan waktu tetap.

Hasilnya akan terlihat seperti ini, test yang membuka browser dan melakukan semua langkah itu secara otomatis.

test('alur login sampai checkout', async ({ page }) => {
  await page.goto('/login');
  await page.getByTestId('email').fill('test@mail.com');
  await page.getByTestId('password').fill('rahasia123');
  await page.getByTestId('btn-login').click();
  await expect(page).toHaveURL('/produk');
  await page.getByTestId('btn-tambah').first().click();
  await expect(page.getByTestId('ikon-keranjang')).toHaveText('1');
});

Menjalankan Test dan Membaca Hasilnya

Menjalankannya biasanya satu perintah, misalnya npx playwright test atau npx cypress open. Hasilnya ditampilkan per skenario: hijau berarti lolos, merah berarti gagal. Saat gagal, kedua tools ini otomatis menyimpan screenshot keadaan halaman persis saat kegagalan terjadi, bahkan ada rekaman videonya. Ini emas untuk debugging.

Cara membacanya: lihat dulu di langkah ke berapa test berhenti. Lalu buka screenshot-nya. Apakah halamannya blank? Apakah tombolnya tidak ada? Apakah teks yang diharapkan tidak muncul? Salin pesan error plus screenshot itu ke AI, dan minta dia menganalisis penyebabnya. Polanya sama seperti debugging biasa, hanya saja yang menemukan bug-nya adalah robot, bukan kamu yang mengklik manual 20 kali.

Jebakan Flaky Test

Ada satu jebakan yang membuat banyak pemula frustrasi dan akhirnya membenci E2E test: flaky test, yaitu test yang kadang lolos kadang gagal padahal kodenya tidak berubah sama sekali. Penyebabnya hampir selalu soal waktu. Contoh klasiknya adalah perintah "tunggu 3 detik lalu klik", yang lolos saat internet cepat dan gagal saat internet lambat. Penyebab lain adalah selector yang rapuh, misalnya mencari tombol berdasarkan teks yang ternyata berubah-ubah, atau data test yang tidak di-reset sehingga test kedua gagal karena data dari test pertama masih ada.

Solusinya tiga. Pertama, jangan pakai jeda waktu tetap, manfaatkan fitur tunggu otomatis bawaan Playwright dan Cypress yang menunggu elemen benar-benar siap. Kedua, pakai selector yang stabil seperti data-testid, atribut khusus yang tidak berubah walau teks atau tampilannya diganti. Ketiga, reset data test setiap kali test berjalan. Kalau kamu menemukan test yang flaky, jangan langsung menyalahkan tools-nya. Tempelkan test itu ke AI dengan prompt seperti ini.

Test E2E di bawah ini flaky: kadang lolos kadang gagal tanpa perubahan kode.
Analisis penyebab flakiness-nya (timing, selector rapuh, atau data test),
lalu tulis ulang dengan menunggu otomatis bawaan Playwright
dan selector data-testid yang stabil. Jelaskan tiap perubahan yang kamu buat.

[kode test yang flaky ditempel di sini]

Latihan Minggu Ini

Latihanmu minggu ini tiga langkah. Pertama, pilih satu alur kritis di aplikasimu, yang paling memalukan kalau rusak, misalnya login atau checkout. Kedua, minta AI buatkan satu file E2E test untuk alur itu dengan prompt yang strukturnya seperti contoh di atas. Ketiga, jalankan test itu lima kali berturut-turut dan catat: apakah selalu lolos? Kalau ada yang gagal padahal kode tidak berubah, kamu baru saja menemukan flaky test pertamamu, dan sekarang kamu tahu cara memperbaikinya.

Di episode 15 kita naik satu level lagi, dari "aplikasinya jalan" ke "aplikasinya aman", dengan judul "Review Keamanan Kode AI: Jebakan yang Sering Lolos". Karena aplikasi yang berjalan sempurna tapi bocor datanya bukanlah aplikasi yang selesai. Sampai jumpa besok jam 21:00. Bakar semangat kodingmu seperti api kompor.