Learn Jest - Use Cases & Testing Patterns

#Introduction

All the techniques you've learned now come together as real testing patterns. Episode 20 covers concrete use cases for three types of projects — frontend apps, API clients, and library packages — then explores behavior-driven testing patterns, data-driven tests with parameterized cases, and test organization best practices.

Good patterns are born from experience, and this episode collects the ones that have most often proven useful. After this, you won't just know Jest's API; you'll know when and how to use each piece.

#Use Case: Frontend App

#Testing Component Behavior

For a frontend app, focus on behavior visible to users. The combination of React Testing Library and user-event gives a realistic picture:

Frontend use case: login form

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();
});

This test exercises a real interaction: the user clicks the button without filling the form, and the app responds with an error message. This pattern is more valuable than inspecting a component's internal details.

#Use Case: API Client

#Testing the Client with a Mocked Transport

For an API client, mock the transport, then test the request-building and response-parsing logic:

API client use case with mocked fetch

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") and expect.objectContaining are asymmetric matchers — they check part of a value rather than the whole. They're perfect for validating that the URL and headers are correct without being tied to unimportant details.

#Use Case: Library Package

#Testing the Library's Public API

For a library package, focus on the public API contract — what consumers of the library use:

Library use case: public API contract

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

Library tests emphasize stability: once an API is published, behavior changes can break consumers. Asserting exact output for various inputs is the clearest form of a contract.

#Behavior-Driven Testing Patterns

#Given, When, Then

The behavior-driven testing (BDD) pattern structures a test as a narrative flow: initial state, action, and expected result.

BDD given-when-then pattern

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);
  });
});

The given, when, and then comments make the test read like a story. This structure helps reviewers understand the flow without having to guess the intent of the assertions.

#Data-Driven Tests & Parameterized Cases

#test.each for Many Cases

Instead of writing a separate test for each input, test.each generates many tests from a single data table:

Parameterized test with 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([...]) accepts a data array, and each row becomes its own test with a name interpolated from the arguments. When one case fails, you immediately know which input is the problem.

#When to Use test.each

Use test.each when there are many cases but the pattern is the same. Avoid it when each case needs significantly different setup — in that situation, separate explicit tests are clearer.

#Test Organization Best Practices

#Consistent Structure

A few organizational rules keep the suite maintainable:

• One describe block per module or feature, with a clear name.
• Group tests by behavior, not implementation.
• Keep one test for one behavior; don't pile up unrelated assertions.
• Put helpers in separate modules so they can be shared.

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

The structure above places tests next to the source code, with helpers separated into their own module. Consistent structure keeps the suite easy to navigate as the project grows.

#Wrap Up

Episode 20 brought everything together into real patterns: use cases for frontend apps, API clients, and library packages, the BDD given-when-then pattern, data-driven tests with test.each, and test organization best practices.

Key takeaways:

• Frontend is tested through user behavior with Testing Library.
• API clients are tested with a mocked transport and asymmetric matchers.
• Library packages are tested on their public API contract.
• The BDD pattern makes tests read like a story.
• test.each generates many tests from a single data table.
• Consistent structure and one behavior per test keep the suite maintainable.

In the next episode, episode 21, we'll cover the ecosystem & tools — Testing Library, Cypress, Playwright, and ESLint, Jest community plugins and utilities, debugging tests in the IDE, and official learning resources.