Bagaimanakah anda menguji logik keadaan?

Question

Accepted Answer

Menguji logik keadaan membina kepercayaan bahawa peralihan dan kemas kini keadaan anda adalah betul. Strategi bergantung pada *bagaimana* logik tersebut berstruktur — fungsi tulen (reducer) adalah yang paling mudah diuji, jadi keadaan yang dirancang dengan baik juga merupakan keadaan yang boleh diuji dengan baik.

## Menguji reducer tulen secara langsung (kes paling mudah, nilai tertinggi)

```js
// reducers are pure: (state, action) => newState → trivial to test, no mocks
describe("todosReducer", () => {
  it("adds a todo", () => {
    const initial = [];
    const next = todosReducer(initial, { type: "todos/added", payload: { id: 1, text: "A" } });
    expect(next).toEqual([{ id: 1, text: "A" }]);
    expect(initial).toEqual([]); // ✅ verify the original wasn't mutated (immutability)
  });
});
```

Kerana reducer adalah fungsi tulen, anda hanya memanggilnya dengan input dan menyatakan output — tanpa rendering, tanpa mocking, cepat dan deterministik. Ini adalah *alasan* mengapa corak pure-reducer sangat dihargai.

## Menguji pemilih

```js
it("selects the cart total", () => {
  const state = { cart: { items: [{ price: 10 }, { price: 5 }] } };
  expect(selectCartTotal(state)).toBe(15);
});
```

## Menguji hook tersuai / logik kedai

```jsx
import { renderHook, act } from "@testing-library/react";

it("increments", () => {
  const { result } = renderHook(() => useCounter());
  act(() => result.current.increment()); // act wraps state updates
  expect(result.current.count).toBe(1);
});
```

`renderHook` + `act` membenarkan anda menguji logik keadaan hook/stor secara terpencil.

## Menguji komponen mengikut kelakuan, bukan dalaman

```jsx
import { render, screen, fireEvent } from "@testing-library/react";

it("shows the count after clicking", () => {
  render(<Counter />);
  fireEvent.click(screen.getByRole("button"));
  expect(screen.getByText("1")).toBeInTheDocument(); // assert the rendered RESULT
});
```

Uji apa yang dilihat/dilakukan pengguna (kelakuan), bukan butiran pelaksanaan — jadi refactor tidak merosakkan ujian.

## Menguji keadaan tak segerak (mock rangkaian)

```js
// mock fetch/API (e.g. MSW), then assert loading → success/error transitions
it("handles fetch error → error state", async () => { ... });
```

Gunakan MSW atau mock untuk menguji peralihan loading/success/error secara deterministik.

## Apa yang perlu diutamakan

```text
Reducers/selectors/pure logic → unit test thoroughly (cheap, high value)
Component behavior           → integration test key user flows
Async flows                  → test transitions with mocked APIs
Don't test framework internals or trivial setters
```

## Mengapa ia penting

Bug keadaan adalah antara yang paling berdampak, jadi menguji logik keadaan adalah nilai tinggi.

Dengan ketara, **keadaan yang berstruktur dengan baik pada asasnya boleh diuji**: reducer tulen dan pemilih adalah remeh untuk ujian unit (tanpa mock, deterministik), yang merupakan hujah kuat untuk seni bina tersebut.

Mengetahui cara menguji reducer/pemilih secara langsung, hook dengan `renderHook`, komponen mengikut kelakuan yang kelihatan kepada pengguna, dan aliran tak segerak dengan rangkaian yang dipalsukan — sambil mengelak ujian butiran pelaksanaan yang rapuh — memberikan perlindungan yang boleh dipercayai bagi logik yang paling mungkin menyebabkan bug halus.