Belajar Jest - Use Cases & Testing Patterns

#Pendahuluan

Seluruh teknik yang sudah kalian pelajari sekarang disatukan menjadi pola testing nyata. Episode 20 membahas use case konkret untuk tiga jenis project — frontend app, API client, dan library package — lalu mempelajari pola behavior-driven testing, data-driven test dengan parameterized cases, serta best practices pengorganisasian test.

Pola yang baik lahir dari pengalaman, dan episode ini mengumpulkan pola yang paling sering terbukti berguna. Setelah ini, kalian bukan hanya tahu API Jest, tetapi tahu kapan dan bagaimana memakai setiap bagiannya.

#Use Case: Frontend App

#Menguji Perilaku Komponen

Untuk frontend app, fokus pada perilaku yang terlihat pengguna. Kombinasi React Testing Library dan user-event memberi gambaran nyata:

Use case frontend: form login

test("form login menampilkan error saat kosong", async () => {
  render(<FormLogin />);
  await user.click(screen.getByRole("button", { name: "Masuk" }));
 
  expect(screen.getByText("Email wajib diisi")).toBeInTheDocument();
});

Test ini menguji interaksi nyata: pengguna mengklik tombol tanpa mengisi form, dan aplikasi merespons dengan pesan error. Pola ini lebih berharga daripada memeriksa detail internal komponen.

#Use Case: API Client

#Menguji Client dengan Transport di-Mock

Untuk API client, mock transport lalu uji logika penyusunan request dan penguraian respons:

Use case API client dengan fetch di-mock

test("client menambah header otentikasi", async () => {
  fetch.mockResolvedValue({ ok: true, json: async () => ({ ok: 1 }) });
 
  await client.getStatus();
  expect(fetch).toHaveBeenCalledWith(
    expect.stringContaining("/status"),
    expect.objectContaining({ headers: expect.any(Object) }),
  );
});

expect.stringContaining("/status") dan expect.objectContaining adalah asymmetric matchers — memeriksa sebagian daripada seluruh nilai. Cocok untuk memvalidasi bahwa URL dan header benar tanpa terikat pada detail yang tidak penting.

#Use Case: Library Package

#Menguji API Publik Library

Untuk library package, fokus pada kontrak API publik — apa yang dipakai konsumen library:

Use case library: kontrak API publik

test("formatRupiah memformat angka dengan benar", () => {
  expect(formatRupiah(1250000)).toBe("Rp1.250.000");
  expect(formatRupiah(0)).toBe("Rp0");
});

Test library menekankan stabilitas: begitu API dipublikasikan, perubahan perilaku bisa memecahkan konsumen. Assertion terhadap output eksak untuk berbagai input adalah bentuk kontrak yang paling jelas.

#Behavior-Driven Testing Patterns

#Given, When, Then

Pola behavior-driven testing (BDD) menyusun test dengan alur naratif: kondisi awal, aksi, dan hasil yang diharapkan.

Pola BDD given-when-then

describe("keranjang belanja", () => {
  test("menambahkan barang menaikkan total", () => {
    // given
    const keranjang = buatKeranjang();
    // when
    keranjang.tambah({ harga: 10000, qty: 2 });
    // when
    keranjang.tambah({ harga: 5000, qty: 1 });
    // then
    expect(keranjang.total()).toBe(25000);
  });
});

Komentar given, when, dan then membuat test terbaca seperti cerita. Struktur ini membantu reviewer memahami alur tanpa harus menebak maksud assertion.

#Data-Driven Tests dan Parameterized Cases

#test.each untuk Banyak Kasus

Alih-alih menulis test terpisah untuk setiap input, test.each menghasilkan banyak test dari satu tabel data:

Parameterized test dengan test.each

test.each([
  [10, 2, 5],
  [9, 3, 3],
  [7, 2, 3.5],
])("bagi %i dengan %i menghasilkan %i", (a, b, hasil) => {
  expect(bagi(a, b)).toBeCloseTo(hasil);
});

test.each([...]) menerima array data, dan setiap baris menjadi satu test terpisah dengan nama yang diinterpolasi dari argumen. Ketika satu kasus gagal, kalian langsung tahu input mana yang bermasalah.

#Kapan Menggunakan test.each

Gunakan test.each saat kasusnya banyak tetapi polanya sama. Hindari jika tiap kasus butuh setup berbeda yang signifikan — dalam situasi itu, test terpisah yang eksplisit lebih jelas.

#Best Practices Pengorganisasian Test

#Struktur yang Konsisten

Beberapa aturan organisasi yang menjaga suite tetap terpelihara:

• Satu blok describe per modul atau fitur, dengan nama yang jelas.
• Kelompokkan test berdasarkan perilaku, bukan implementasi.
• Jaga satu test untuk satu perilaku; jangan menumpuk assertion tak terkait.
• Letakkan helper di modul terpisah agar bisa dibagikan.

src/
  keranjang/
    keranjang.js
    keranjang.test.js
    keranjang.helpers.js

Struktur di atas menempatkan test di samping kode sumber, dengan helper dipisah ke modul sendiri. Konsistensi struktur membuat suite mudah dinavigasi seiring pertumbuhan project.

#Penutup

Episode 20 menyatukan semuanya menjadi pola nyata: use case untuk frontend app, API client, dan library package, pola BDD given-when-then, data-driven test dengan test.each, serta best practices pengorganisasian test.

Inti yang harus dibawa pulang:

• Frontend diuji lewat perilaku pengguna dengan Testing Library.
• API client diuji dengan transport di-mock dan asymmetric matchers.
• Library package diuji pada kontrak API publiknya.
• Pola BDD membuat test terbaca seperti cerita.
• test.each menghasilkan banyak test dari satu tabel data.
• Konsistensi struktur dan satu perilaku per test menjaga suite terpelihara.

Di episode 21 selanjutnya kita akan membahas ekosistem & tools — Testing Library, Cypress, Playwright, dan ESLint, plugin serta utilitas komunitas Jest, debugging test di IDE, dan sumber belajar resmi.