Belajar Playwright - Test Coverage & Performance

#Pendahuluan

Seberapa banyak aplikasi yang benar-benar diuji? Dan seberapa cepat halaman itu dimuat? Episode 11 ini membahas dua pertanyaan yang sering terlewat saat tim sibuk menambah test: coverage — memastikan semua lapisan teruji — dan performance — memastikan aplikasi tidak hanya benar, tapi juga cepat.

Keduanya berbagi alat yang sama: tracing dan browser metrics yang bisa diambil langsung dari Playwright. Kalian akan belajar mengukur seberapa luas coverage suite kalian, membaca timing halaman seperti yang dialami pengguna nyata, dan membuat snapshot visual yang menangkap perubahan tidak terduga di masa depan.

#Mengukur Coverage untuk Berbagai Jenis Test

#Peta Coverage Berdasarkan Test Pyramid

Test pyramid memberikan arah: banyak unit test di dasar, sebagian integration di tengah, sedikit end-to-end di puncak. Untuk mengukur coverage secara menyeluruh, kalian perlu memantau tiga lapisan tersebut secara terpisah:

Unit coverage: persentase baris dan cabang kode yang dieksekusi unit test.
Integration coverage: interaksi antar modul, service, dan database.
Functional/end-to-end coverage: alur bisnis lengkap melalui antarmuka.

#Coverage End-to-End Secara Manual

Playwright tidak menghitung line coverage aplikasi secara otomatis — itu tugas tool di layer unit. Untuk layer end-to-end, coverage diukur secara semantik: peta fitur aplikasi yang masing-masing dipetakan ke set test. Contoh peta sederhana:

Peta fitur ke test

fitur login → tests/login.spec.ts
fitur checkout → tests/checkout.spec.ts
fitur dashboard → tests/dashboard.spec.ts

Dengan peta ini, kalian bisa melihat fitur mana yang belum punya test sama sekali. Coverage end-to-end yang sehat bukan soal persentase baris, melainkan soal setiap jalur bisnis penting memiliki pelindungnya.

#Mengukur Coverage Unit dengan C8 atau V8

Untuk lapisan unit, gunakan tool coverage standar seperti Istanbul atau V8 coverage pada runner unit test kalian. Integrasikan hasilnya ke CI agar penurunan coverage langsung terlihat. Ingat: angka coverage hanyalah sinyal — yang lebih penting adalah kasus tepi dan alur kritis yang benar-benar teruji.

#Performance Insights dengan Tracing dan Browser Performance

#Mengambil Timing dengan Performance API

Browser modern menyimpan timing setiap halaman yang bisa dibaca langsung dari konteks Playwright:

Baca performance timing

import { test, expect } from '@playwright/test';
 
test('mengukur page load', async ({ page }) => {
  await page.goto('/beranda');
  const timing = await page.evaluate(() => {
    const { navigationStart, loadEventEnd, domContentLoadedEventEnd } = performance.timing;
    return {
      loadMs: loadEventEnd - navigationStart,
      domReadyMs: domContentLoadedEventEnd - navigationStart,
    };
  });
  console.log('durasi load:', timing.loadMs);
});

page.evaluate(() => performance.timing) mengeksekusi JavaScript di dalam halaman dan mengembalikan hasilnya ke test. Dengan ini, kalian bisa mengukur durasi load untuk setiap test dan menandai regresi saat angka membengkak.

#Core Web Vitals dari Konteks

Untuk metrik pengguna seperti Largest Contentful Paint, Playwright mempermudah pengambilan data dari PerformanceObserver:

Ambil LCP dari halaman

const lcp = await page.evaluate(async () => {
  return await new Promise((resolve) => {
    new PerformanceObserver((list) => {
      const entries = list.getEntries();
      resolve(entries.at(-1)?.startTime ?? 0);
    }).observe({ type: 'largest-contentful-paint', buffered: true });
  });
});
console.log('LCP (ms):', lcp);

PerformanceObserver menangkap nilai LCP secara real-time. Dengan mengumpulkan metrik ini di beberapa test, kalian membangun bank data performance yang bisa dibandingkan antar rilis.

#Tracing untuk Menyelidiki Bottleneck

Trace tidak hanya untuk debugging test, tapi juga untuk memahami perilaku aplikasi:

Aktifkan trace untuk investigasi

test.use({ trace: 'on' });
 
test('selidiki performa checkout', async ({ page }) => {
  await page.goto('/checkout');
  // aksi ...
});

test.use({ trace: 'on' }) membuat trace untuk test ini. Di trace viewer, bagian Network dan Timing menunjukkan berapa lama setiap request berjalan — titik awal yang baik untuk menemukan slow API atau resource yang besar.

#Mengukur Page Load dan Responsiveness

#Memantau Waktu Interaction

Selain load, ukur seberapa cepat halaman merespons interaksi — inilah esensi responsiveness:

Ukur durasi klik hingga response

const start = Date.now();
await page.getByRole('button', { name: 'Simpan' }).click();
await expect(page.getByText('Tersimpan')).toBeVisible();
console.log('responsiveness (ms):', Date.now() - start);

Dengan mengukur rentang dari klik sampai elemen hasil tampil, kalian mendapat gambaran end-to-end tentang seberapa responsif satu aksi. Buatlah ini menjadi helper agar semua test memakai metrik yang sama.

#Menetapkan Ambang Batas

Metrik tanpa ambang batas hanya menghasilkan angka. Tetapkan nilai yang wajar dan biarkan test memantau:

Assertion ambang batas performa

expect(lcp).toBeLessThan(2500);

expect(lcp).toBeLessThan(2500) mengubah pengukuran menjadi assertion. Jika LCP melewati 2,5 detik, test gagal — regression performa terdeteksi sebelum sampai ke produksi.

#Snapshot Testing dan Deteksi Perubahan Visual

#Konsep Snapshot

Snapshot testing mengambil baseline gambar halaman dan membandingkannya dengan versi terbaru:

Snapshot halaman

await expect(page).toHaveScreenshot('beranda.png');

page.toHaveScreenshot('beranda.png') pada lari pertama menyimpan gambar baseline; pada lari berikutnya membandingkan dengan gambar saat ini. Perbedaan pixel akan membuat test gagal, menandakan ada perubahan visual yang belum disetujui.

#Mengelola Baseline di Repo

Baseline snapshot disimpan di folder __screenshots__ atau sesuai konfigurasi, dan harus di-commit ke repository. Saat perubahan visual memang disengaja, update baseline dengan npx playwright test --update-snapshots. Detail lengkap visual regression, termasuk thresholding dan layout drift, akan kita bahas di episode 16.

Perbarui baseline snapshot

npx playwright test --update-snapshots

#Penutup

Episode 11 melengkapi kalian dengan dua lensa pengawasan: coverage yang memetakan setiap fitur ke test di semua lapisan pyramid, dan performance yang diukur langsung dari dalam browser lewat timing API, Core Web Vitals, dan tracing. Snapshot testing mulai memperkenalkan kalian pada deteksi perubahan visual otomatis.

Inti yang harus dibawa pulang:

Coverage end-to-end diukur dengan memetakan fitur ke test, bukan sekadar persentase baris.
page.evaluate mengambil timing dan Core Web Vitals dari dalam halaman.
Trace membantu menemukan slow API dan resource penyebab bottleneck.
Ubah metrik menjadi assertion dengan ambang batas agar regresi terdeteksi.
Snapshot toHaveScreenshot menjadi alarm pertama perubahan visual.

Di episode 12 selanjutnya kita akan membahas API testing dan network interception — mocking response API dengan route interception, menguji offline mode dan network failures, memvalidasi perilaku backend lewat alur UI, serta integrasi dengan API test tools.