आप स्टेट लॉजिक का परीक्षण कैसे करते हैं?

Question

Accepted Answer

स्टेट लॉजिक का परीक्षण करने से यह आत्मविश्वास मिलता है कि आपके स्टेट ट्रांजीशन और अपडेट सही हैं। रणनीति इस बात पर निर्भर करती है कि लॉजिक *कैसे* संरचित है — शुद्ध फंक्शन (reducers) परीक्षण करने में सबसे आसान होते हैं, इसलिए अच्छी तरह से आर्किटेक्ट किया गया स्टेट भी अच्छी तरह से परीक्षण योग्य स्टेट है।

## शुद्ध reducers को सीधे परीक्षण करें (सबसे आसान, उच्चतम-मूल्य का मामला)

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

चूंकि reducers शुद्ध फंक्शन हैं, आप उन्हें इनपुट के साथ कॉल करते हैं और आउटपुट को assert करते हैं — कोई रेंडरिंग नहीं, कोई mocking नहीं, तेज़ और निर्धारक। यह *कारण है* कि शुद्ध-reducer पैटर्न इतना मूल्यवान है।

## Selectors का परीक्षण करें

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

## कस्टम hooks / 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` आपको hook/store स्टेट लॉजिक को अलगथलग परीक्षण करने देते हैं।

## Components का परीक्षण व्यवहार के आधार पर करें, internals नहीं

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

जो कुछ user देखता/करता है उसका परीक्षण करें (व्यवहार), implementation details नहीं — ताकि refactors tests को तोड़ न दें।

## Async state का परीक्षण करें (network को mock करें)

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

loading/success/error transitions का परीक्षण deterministically करने के लिए MSW या mocks का उपयोग करें।

## क्या प्राथमिकता दें

```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 bugs सबसे प्रभावशाली होते हैं, इसलिए state logic का परीक्षण उच्च-मूल्य वाला है।

मुख्य रूप से, **अच्छी तरह से संरचित state स्वाभाविक रूप से परीक्षण योग्य है**: शुद्ध reducers और selectors unit test करने में तुच्छ हैं (कोई mocks नहीं, deterministic), जो इस architecture के लिए एक मजबूत तर्क है।

reducers/selectors का सीधे परीक्षण करना, `renderHook` के साथ hooks, user-visible behavior के आधार पर components, और mocked networks के साथ async flows जानना — जबकि brittle implementation-detail tests से बचना — सूक्ष्म bugs के कारण होने वाली logic का विश्वसनीय coverage प्रदान करता है।