คุณจะทดสอบ logic ของ state อย่างไร?

Question

Accepted Answer

การทดสอบ logic ของ state สร้างความมั่นใจว่า state transition และการอัปเดตของคุณถูกต้อง กลยุทธ์ขึ้นอยู่กับ *วิธีที่* logic ถูกจัดโครงสร้าง โดย pure function (reducer) ทดสอบได้ง่ายที่สุด ดังนั้น state ที่ออกแบบสถาปัตยกรรมมาดีจึงเป็น state ที่ทดสอบได้ดีด้วย

## ทดสอบ pure reducer โดยตรง (กรณีที่ง่ายที่สุดและมีคุณค่าสูงสุด)

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

เนื่องจาก reducer เป็น pure function คุณเพียงแค่เรียกมันด้วย input และตรวจสอบ output โดยไม่ต้อง render ไม่ต้อง mock รวดเร็วและคาดเดาได้ (deterministic) นี่คือ *เหตุผล* ที่รูปแบบ pure reducer มีคุณค่ามาก

## ทดสอบ selector

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

## ทดสอบ custom hook / logic ของ store

```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` ช่วยให้คุณทดสอบ logic ของ state ใน hook/store แบบแยกส่วนได้

## ทดสอบคอมโพเนนต์ตามพฤติกรรม ไม่ใช่ตามรายละเอียดภายใน

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

ทดสอบสิ่งที่ผู้ใช้เห็น/ทำ (พฤติกรรม) ไม่ใช่รายละเอียดการ implement เพื่อให้การ refactor ไม่ทำให้เทสต์พัง

## ทดสอบ async state (mock network)

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

ใช้ MSW หรือ mock เพื่อทดสอบ transition ของ loading/success/error อย่างคาดเดาได้

## ควรให้ความสำคัญกับอะไร

```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
```

## ทำไมจึงสำคัญ

บั๊กของ state เป็นหนึ่งในสิ่งที่มีผลกระทบมากที่สุด การทดสอบ logic ของ state จึงมีคุณค่าสูง

ที่สำคัญ **state ที่มีโครงสร้างดีย่อมทดสอบได้โดยธรรมชาติ**: pure reducer และ selector ทดสอบ unit ได้ง่ายมาก (ไม่ต้อง mock, คาดเดาได้) ซึ่งเป็นเหตุผลที่หนักแน่นในการเลือกสถาปัตยกรรมแบบนั้น

การรู้ที่จะทดสอบ reducer/selector โดยตรง, ทดสอบ hook ด้วย `renderHook`, ทดสอบคอมโพเนนต์ตามพฤติกรรมที่ผู้ใช้มองเห็น และทดสอบ async flow ด้วย network ที่ถูก mock ในขณะที่หลีกเลี่ยงเทสต์ที่เปราะบางซึ่งผูกกับรายละเอียดการ implement จะให้ความครอบคลุมที่เชื่อถือได้ของ logic ที่มีแนวโน้มก่อให้เกิดบั๊กที่ละเอียดอ่อนที่สุด