Belajar Playwright - Real-world Use Cases & Patterns

#Pendahuluan

Semua konsep yang sudah kalian pelajari menemukan maknanya saat dipakai pada aplikasi nyata. Episode 20 ini membawa teori ke praktik: tiga use case paling umum dalam bisnis digital — checkout e-commerce, signup flow, dan dashboard workflow — lengkap dengan pola test yang terbukti bekerja di lapangan.

Selain menulis test, episode ini membahas strategi: bagaimana menyeimbangkan investasi antara UI test, API test, dan component test, serta bagaimana memprioritaskan jalur bisnis yang paling penting untuk dilindungi pertama kali. Kemampuan memilih apa yang harus diuji sama pentingnya dengan cara menguji.

#Use Case: E-commerce Checkout

#Pola Test Checkout

Checkout adalah jalur paling kritis di e-commerce — kegagalan di sini berarti kehilangan pendapatan langsung. Test checkout harus memakai Page Object (episode 6) dan mock API (episode 12) agar tidak bergantung pada payment gateway asli:

Test checkout dengan mock pembayaran

import { test, expect } from '@playwright/test';
import { CheckoutPage } from '../pages/CheckoutPage';
 
test('checkout sukses sampai halaman konfirmasi', async ({ page }) => {
  await page.route('**/api/payment', (route) => {
    route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ status: 'success', orderId: 'ORD-001' }),
    });
  });
 
  const checkout = new CheckoutPage(page);
  await checkout.goto();
  await checkout.isiAlamatPengiriman();
  await checkout.pilihMetodePembayaran('transfer');
  await checkout.bayar();
  await expect(page.getByText('Pesanan berhasil dibuat')).toBeVisible();
  await expect(page).toHaveURL(/konfirmasi/);
});

route.fulfill pada **/api/payment menggantikan gateway pembayaran dengan respons sukses yang terkontrol. Alur UI lengkap — dari alamat sampai konfirmasi — diuji tanpa uang sungguhan.

#Kasus Gagal yang Wajib Diuji

Selain happy path, uji jalur gagal checkout yang paling umum:

Kartu ditolak — pastikan pesan error dan state form dipertahankan.
Alamat tidak lengkap — validasi muncul sebelum pembayaran.
Stok habis saat checkout — konfirmasi keranjang diperbarui.

Test checkout gagal

await page.route('**/api/payment', (route) => {
  route.fulfill({
    status: 402,
    contentType: 'application/json',
    body: JSON.stringify({ error: 'Pembayaran ditolak' }),
  });
});
await checkout.bayar();
await expect(page.getByText('Pembayaran ditolak')).toBeVisible();

status: 402 mensimulasikan pembayaran yang ditolak. Verifikasi bahwa UI menampilkan error dengan benar dan tidak terjebak dalam state loading.

Signup menggabungkan validasi frontend dan backend sekaligus. Kunci test yang stabil adalah menggunakan data unik (episode 13) agar tidak tabrakan dengan user yang sudah ada:

Test signup flow

import { test, expect } from '@playwright/test';
 
test('pendaftaran akun baru berhasil', async ({ page }) => {
  const email = `user-${Date.now()}@example.com`;
  await page.goto('/daftar');
  await page.getByLabel('Nama Lengkap').fill('Budi Santoso');
  await page.getByLabel('Email').fill(email);
  await page.getByLabel('Kata Sandi').fill('Rahasia123!');
  await page.getByLabel('Konfirmasi Kata Sandi').fill('Rahasia123!');
  await page.getByRole('button', { name: 'Daftar' }).click();
 
  await expect(page.getByText('Verifikasi email dikirim')).toBeVisible();
  await expect(page).toHaveURL(/cek-email/);
});

email = 'user-${Date.now()}@example.com' menjamin keunikan di setiap eksekusi. Setelah submit, verifikasi konfirmasi pengiriman email — titik di mana alur UI berakhir untuk user baru.

#Skenario Validasi yang Bernilai

Signup rentan terhadap kebocoran state antar field. Uji beberapa validasi dalam satu describe agar kegagalan terkumpul:

Validasi password lemah

await page.getByLabel('Kata Sandi').fill('123');
await page.getByRole('button', { name: 'Daftar' }).click();
await expect(page.getByText('Kata sandi minimal 8 karakter')).toBeVisible();

Memverifikasi pesan validasi yang spesifik menegaskan bahwa aturan backend dan frontend sinkron — bug umum ketika satu sisi mengizinkan password yang sisi lain tolak.

#Use Case: Dashboard Workflows

#Pola Test Dashboard

Dashboard biasanya memuat banyak data asinkron dari beberapa API sekaligus. Stabilitas test dicapai dengan mengendalikan setiap respons:

Test dashboard dengan data terkontrol

import { test, expect } from '@playwright/test';
 
test('dashboard menampilkan metrik dari API', async ({ page }) => {
  await page.route('**/api/metrics', (route) => {
    route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ revenue: 12000000, orders: 340 }),
    });
  });
 
  await page.goto('/dashboard');
  await expect(page.getByText('12.000.000')).toBeVisible();
  await expect(page.getByText('340')).toBeVisible();
});

Dengan route yang mengendalikan **/api/metrics, nilai yang dirender bisa ditebak persis. Ini menghilangkan flakiness yang muncul saat data dashboard berubah antar eksekusi.

#Workflow Aksi di Dashboard

Dashboard sering berisi aksi — filter, sort, export. Uji alur aksi paling penting:

Filter laporan di dashboard

await page.getByRole('combobox').selectOption({ label: 'Bulan ini' });
await expect(page.getByText('Laporan Bulan Ini')).toBeVisible();
await page.getByRole('button', { name: 'Export' }).click();
await expect(page.waitForEvent('download')).resolves.toBeTruthy();

Verifikasi bahwa aksi filter mengubah konten, lalu bahwa tombol export memicu download — dua perilaku yang paling sering rusak di dashboard.

#Balancing UI, API, dan Component Tests

#Membagi Beban Antar Lapisan

Bukan semua alur harus diuji di level UI. Aturan praktis pembagian:

API test: validasi kontrak dan logika server — cepat dan murah.
Component test: perilaku komponen individual dalam isolasi.
UI test: alur bisnis lengkap yang melibatkan interaksi nyata pengguna.

Gunakan test pyramid sebagai panduan: mayoritas test di level API dan component, sedikit tapi penting di level UI. Ketika memulai suite, jangan langsung menulis UI test untuk segalanya — mulai dari API test untuk kontrak, tambahkan component test untuk komponen kompleks, dan UI test hanya untuk alur yang benar-benar butuh browser nyata seperti checkout atau login lintas halaman.

#Prioritizing Tests untuk Business-Critical Paths

#Mengidentifikasi Jalur Kritis

Tidak semua fitur bernilai sama. Mulailah dari yang paling berdampak pada pendapatan dan kepercayaan:

Jalur pembayaran: checkout, invoice, refund.
Jalur akses: login, signup, reset password, otorisasi.
Jalur data: upload, export, laporan keuangan.

#Menetapkan Prioritas Berurutan

Tetapkan tingkat prioritas yang terlihat di nama test atau tag — misalnya test('checkout - PRIORITAS TINGGI'). Alur kritis mendapat retry dan monitoring lebih ketat, sementara fitur sekunder boleh lebih longgar.

#Penutup

Episode 20 menghubungkan seluruh keterampilan dengan realitas bisnis: test checkout dengan mock payment, signup dengan data unik, dan dashboard dengan data terkontrol. Kalian juga belajar menyeimbangkan investasi antar lapisan test dan memprioritaskan jalur bisnis kritis yang layak dilindungi pertama kali.

Inti yang harus dibawa pulang:

Mock payment gateway di test checkout untuk menghindari uang sungguhan.
Gunakan data unik (misalnya Date.now()) untuk signup yang bisa diulang.
Kontrol respons API dashboard agar metrik yang dirender bisa ditebak.
Seimbangkan API, component, dan UI test mengikuti test pyramid.
Prioritaskan jalur pembayaran, akses, dan data dengan tanda yang jelas.

Di episode 21 selanjutnya kita akan membahas ekosistem dan tools — tool terkait seperti Testing Library, Percy, dan BrowserStack, penggunaan Playwright Inspector, trace viewer, dan codegen, sumber daya komunitas, serta cloud execution dan managed testing platforms.