ਤੁਸੀਂ state logic ਦੀ ਕਸੌਟੀ ਕਿਵੇਂ ਲੈਂਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

State logic ਦੀ ਕਸੌਟੀ ਲੈਣ ਨਾਲ ਤੁਹਾਨੂੰ ਇਹ ਵਿਸ਼ਵਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ state transitions ਅਤੇ updates ਸਹੀ ਹਨ। ਇਹ ਕਾਰਨਾਮਾ ਇਸ ਗੱਲ ਉੱਪਰ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ logic ਕਿਵੇਂ ਲਿਖੀ ਗਈ ਹੈ — pure functions (reducers) ਨੂੰ ਟੈਸਟ ਕਰਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ, ਇਸ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ state ਵੀ ਚੰਗੀ ਤਰ੍ਹਾਂ testable state ਹੁੰਦਾ ਹੈ।

## Pure 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 pure functions ਹਨ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇਨਪੁੱਟ ਦੇ ਨਾਲ ਸਿੱਧੇ ਕਾਲ ਕਰਦੇ ਹੋ ਅਤੇ ਆਊਟਪੁੱਟ ਨੂੰ ਦਸਤਖਤ ਕਰਦੇ ਹੋ — ਕੋਈ rendering ਨਹੀਂ, ਕੋਈ mocking ਨਹੀਂ, ਤੇਜ਼ ਅਤੇ deterministic। ਇਹ pure-reducer pattern ਨੂੰ ਇਤਨਾ ਕਦਰ ਮਿਲਣ ਦਾ ਕਾਰਣ ਹੈ।

## Selectors ਦੀ ਕਸੌਟੀ ਲਓ

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

## Custom hooks / store logic ਦੀ ਕਸੌਟੀ ਲਓ

```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 ਨੂੰ ਵੱਖ ਵੱਖ ਟੈਸਟ ਕਰਨ ਦਿੰਦੇ ਹਨ।

## Components ਨੂੰ behavior ਦੁਆਰਾ ਟੈਸਟ ਕਰੋ, 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
});
```

ਜੋ ਯੂਜ਼ਰ ਦੇਖਦਾ/ਕਰਦਾ ਹੈ (behavior) ਟੈਸਟ ਕਰੋ, ਲਾਗੂ ਕਰਨ ਦੇ ਵੇਰਵਿਆਂ ਨਹੀਂ — ਇਸ ਲਈ 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 ਸਵਾਭਾਵਿਕ ਤੌਰ 'ਤੇ testable ਹੈ**: pure reducers ਅਤੇ selectors unit ਟੈਸਟ ਕਰਨਾ ਬਿਲਕੁਲ ਸੌਖਾ ਹੈ (ਕੋਈ mocks ਨਹੀਂ, deterministic), ਜੋ ਉਸ architecture ਦਲੀਲ ਵਾਲਾ ਹੈ।

ਜਾਣਨਾ ਕਿ ਤੁਸੀਂ reducers/selectors ਨੂੰ ਸਿੱਧੇ, `renderHook` ਦੇ ਨਾਲ hooks, user-visible behavior ਦੁਆਰਾ components, ਅਤੇ mocked networks ਦੇ ਨਾਲ async flows ਟੈਸਟ ਕਰਦੇ ਹੋ — ਜਦੋਂਕਿ fragile implementation-detail tests ਤੋਂ ਬਚਦੇ ਹੋ — ਉਹ logic ਦਾ ਭਰੋਸੇਮੰਦ ਕਵਰੇਜ ਦਿੰਦਾ ਹੈ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ subtle bugs ਦਾ ਕਾਰਣ ਬਣਦਾ ਹੈ।

Pure reducers ਨੂੰ ਸਿੱਧੇ ਟੈਸਟ ਕਰੋ (ਸਭ ਤੋਂ ਆਸਾਨ, ਸਭ ਤੋਂ ਵੱਡੀ ਮਾਲੀਅਤ ਵਾਲਾ ਕੇਸ)

Selectors ਦੀ ਕਸੌਟੀ ਲਓ

Custom hooks / store logic ਦੀ ਕਸੌਟੀ ਲਓ

Components ਨੂੰ behavior ਦੁਆਰਾ ਟੈਸਟ ਕਰੋ, internals ਦੁਆਰਾ ਨਹੀਂ

Async state ਦੀ ਕਸੌਟੀ ਲਓ (network ਨੂੰ mock ਕਰੋ)

ਪ੍ਰਾਧਾਨਤਾ ਕੀ ਦਿਓ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ