آپ state logic کو کیسے test کرتے ہیں؟

Question

Accepted Answer

Testing state logic سے آپ کو اعتماد ملتا ہے کہ آپ کی state transitions اور updates درست ہیں۔ Strategy *کس طرح* logic structure کی گئی ہے اس پر منحصر ہے — pure functions (reducers) سب سے آسان ہیں test کرنے میں، تو اچھی طریقے سے بنائی گئی state بھی اچھی طریقے سے testable ہے۔

## Pure reducers کو براہ راست test کریں (سب سے آسان، سب سے زیادہ قدر والا حالت)

```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 pure functions ہیں، آپ انہیں input کے ساتھ صرف call کرتے ہیں اور output کو assert کرتے ہیں — کوئی rendering نہیں، کوئی mocking نہیں، تیز اور deterministic۔ یہی وجہ ہے کہ pure-reducer pattern کو بہت اہمیت دی جاتی ہے۔

## Selectors کو test کریں

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

## Custom hooks / store logic کو test کریں

```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 state logic کو isolation میں test کرنے دیتے ہیں۔

## Components کو behavior سے test کریں، نہ کہ 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
});
```

اس چیز کو test کریں جو user دیکھتا/کرتا ہے (behavior)، نہ کہ implementation details — تاکہ refactors tests کو نہ توڑیں۔

## Async state کو test کریں (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 test کرنے کے لیے 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 کو test کرنا بہت قیمتی ہے۔

اہم بات یہ ہے کہ **اچھی طریقے سے structured state فطری طور پر testable ہے**: pure reducers اور selectors کو unit test کرنا بہت آسان ہے (کوئی mocks نہیں، deterministic)، جو اس architecture کے لیے ایک مضبوط دلیل ہے۔

یہ جاننا کہ reducers/selectors کو براہ راست کب test کریں، hooks کو `renderHook` سے کب test کریں، components کو user-visible behavior سے کب test کریں، اور async flows کو mocked networks سے کب test کریں — جبکہ brittle implementation-detail tests سے بچتے ہوں — logic کا قابل اعتماد coverage فراہم کرتا ہے جو subtle bugs کا سبب بننے کا سب سے زیادہ امکان رکھتا ہے۔