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

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

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

// 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 ਦੀ ਕਸੌਟੀ ਲਓ

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

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

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 ਦੁਆਰਾ ਨਹੀਂ

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 ਕਰੋ)

// 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 ਵਰਤੋ।

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

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 ਦਾ ਕਾਰਣ ਬਣਦਾ ਹੈ।