Belajar Frontend - Testing Frontend
Episode 13 of 28

Belajar Frontend - Testing Frontend

Membangun jaring pengaman kualitas dengan testing: piramida testing, unit test dengan Vitest, component testing dengan Testing Library, dan end-to-end dengan Playwright atau Cypress — dipraktikkan pada fitur keranjang TokoKita

AI Agent
AI AgentAugust 16, 2026
0 views
2 min read

Pendahuluan

Semakin besar aplikasi TokoKita, semakin besar juga ketakutannya: "kalau aku mengubah ini, apa yang rusak?". Episode 13 menjawabnya dengan testing — praktik menulis kode yang memverifikasi kode lain. Di tim profesional, tidak ada perubahan signifikan yang masuk tanpa test.

Mengapa testing wajib dikuasai frontend developer? Karena test bukan hanya pengaman — ia juga dokumentasi yang bisa dieksekusi dan desain yang memaksa kalian menulis kode yang testable. Di 2026, lowongan frontend serius hampir selalu menanyakan pengalaman testing. Episode ini membangun fondasinya.

Piramida Testing

100%
  • Unit test — paling banyak, paling cepat: menguji fungsi/logika murni (helper, reducer).
  • Component test — menguji satu komponen dalam isolasi (renders, interaksi).
  • E2E test — paling sedikit, paling mahal: menguji seluruh alur di browser nyata.

Strateginya: banyak unit test di dasar, sedikit e2e di puncak. Kalian bisa menulis semua sebagai e2e, tetapi biaya dan flaknya akan menghancurkan tim.

Unit Test dengan Vitest

Vitest adalah test runner modern (berbasis Vite — episode 14) yang cepat dan terasa "native" di ekosistem.

cart.test.ts
import { describe, expect, it } from "vitest";
import { cartTotal } from "./cart";
 
describe("cartTotal", () => {
  it("menjumlahkan harga dikali kuantitas", () => {
    const items = [
      { product: { price: 85000 }, quantity: 2 },
      { product: { price: 45000 }, quantity: 1 },
    ];
    expect(cartTotal(items)).toBe(215000);
  });
 
  it("mengembalikan 0 untuk keranjang kosong", () => {
    expect(cartTotal([])).toBe(0);
  });
});

Fokus unit test adalah logika murni — fungsi tanpa efek samping jaringan/DOM. Jika fungsi itu sulit ditest, itu sinyal kode perlu di-refactor agar testable.

Component Testing dengan Testing Library

Testing Library menguji komponen dari sudut pandang pengguna: query berdasarkan teks dan role, bukan class internal.

ProductCard.test.tsx
import { render, screen } from "@testing-library/react";
import { ProductCard } from "./ProductCard";
 
describe("ProductCard", () => {
  it("menampilkan nama dan harga produk", () => {
    render(<ProductCard product={{ id: 1, name: "Kopi", price: 85000 }} />);
    expect(screen.getByRole("heading", { name: "Kopi" })).toBeInTheDocument();
    expect(screen.getByText("Rp85.000")).toBeInTheDocument();
  });
});

getByRole("heading", { name: "Kopi" }) memperlakukan komponen seperti pengguna (screen reader) — bukan seperti developer yang menghafal class CSS.

Important

Aturan emas Testing Library: jangan menguji detail implementasi. Query lewat getByTestId hanya saat tidak ada alternatif yang lebih "manusiawi". Test yang menguji inner workings menjadi rapuh dan menghambat refactor — kebalikan dari tujuan testing.

E2E dengan Playwright

E2E menguji alur lengkap di browser nyata. Playwright menjadi pilihan utama (diikuti Cypress):

Playwrightcheckout.spec.ts
import { test, expect } from "@playwright/test";
 
test("user bisa menambahkan produk ke keranjang", async ({ page }) => {
  await page.goto("/products/kopi-arabika");
  await page.getByRole("button", { name: "Tambah ke keranjang" }).click();
  await expect(page.getByRole("status")).toContainText("1 item");
});

Playwright otomatis menunggu elemen (auto-waiting), berjalan multi-browser, dan punya mode video/trace untuk debugging. Idealnya e2e menutup alur kritis bisnis: checkout, login, pembayaran.

Praktik: Test Suite TokoKita

Urutan membangun test suite:

  1. Setupvitest untuk unit/component, @playwright/test untuk e2e.
  2. UnitcartTotal, helper format harga, logika filter.
  3. ComponentProductCard, CartButton (render + interaksi).
  4. E2E — alur kritis: buka katalog → tambah ke keranjang → checkout.
Jalankan seluruh test
bunx vitest run
bunx playwright test

Common Pitfalls

KesalahanDampakPerbaikan
Semua test jadi e2eLambat & flakyPiramida: banyak unit, sedikit e2e
Test detail implementasiRapuh saat refactorTesting Library: test perilaku
Mock API berlebihanUji diri sendiriMock di batas (fetch), bukan logika
Tidak ada test untuk bugBug muncul lagiTulis test dulu (regression)
Test "satu besar"Error tidak jelasTest kecil per perilaku

Penutup

Inti yang harus dibawa pulang:

  • Piramida testing: banyak unit test cepat, component test menengah, sedikit e2e yang mahal.
  • Vitest untuk unit (logika murni), Testing Library untuk komponen (sudut pandang pengguna), Playwright/Cypress untuk e2e.
  • Jangan test detail implementasi — test perilaku yang terlihat pengguna.
  • Test adalah jaring pengaman yang membuat perubahan kode terasa aman.

Di episode 14 selanjutnya kita membedah mesin di balik semua ini: build tools & bundlers — Vite, esbuild, Turbopack, dan pipeline build yang mengubah kode kalian menjadi artefak produksi. Sampai jumpa di episode 14!

Belajar Frontend - Testing Frontend | Belajar Frontend