როგორ უკეთ ტესტავთ სახელმწიფო ლოგიკას?

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-ი სუფთა ფუნქციებია, თქვენ უბრალოდ მათ ფუნქციას აჩვეულებთ input-ით და assert აკეთებთ output-ს — არ არის ასახვა, არ არის mocking, სწრაფი და დეტერმინისტული. ეს არის *მიზეზი*, რომელიც saufly-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 სახელმწიფო ლოგიკა იზოლაციაში.

## კომპონენტების ტესტირება ქცევის მიხედვით, არა შინაგანი დეტალების მიხედვით

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

ტესტიროთ რა ხედავს/აკეთებს მომხმარებელი (ქცევა), არა განხორციელების დეტალები — ამიტომ refactors არ ტყდება ტესტებს.

## ასინქრონული სახელმწიფოს ტესტირება (ქსელის mocking)

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

გამოიყენეთ MSW ან mocks-ი ტესტირებისთვის 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
```

## რატომ არის ეს მნიშვნელოვანი

სახელმწიფო ბაგები ერთ-ერთი ყველაზე প্რობლემური, ამიტომ სახელმწიფო ლოგიკის ტესტირება მაღალი ღირებულებაა.

მნიშვნელოვანია, რომ **კარგად სტრუქტურირებული სახელმწიფო თანდაყოლილად ტესტირებადია**: სუფთა reducers-ი და selectors-ი ტრივიალურია unit ტესტირებისთვის (არ არის mocks-ი, დეტერმინისტული), რაც ძლიერი მტკიცებულება არის ამ არქიტექტურისთვის.

ცოდვით ტესტირება reducers-ის/selectors-ის პირდაპირ, hooks-ის `renderHook`-ით, კომპონენტების მომხმარებლის მიერ ხილული ქცევით, და ასინქრონული ნაკადების mocked ქსელების საშუალებით — ხოლო ინდიფერენტული განხორციელების დეტალების ტესტირება თავს იკავებთ — საიმედო დაფარვა აძლევს ლოგიკას, რომელიც მიუთითებს subtle bugs-ებზე.