რა არის ტესტის ფიქსტურები და setup/teardown?

Question

Accepted Answer

**ტესტის ფიქსტურები** არის ფიქსირებული setup (მონაცემები, ობიექტები, მდგომარეობა), რომელიც ტესტებს სჭირდება გასაშვებად, ხოლო **setup/teardown** მეთოდები ამ კონტექსტს ამზადებენ და ტესტების შემდეგ გასუფთავებენ. ისინი აკლებენ დუბლირებას და უზრუნველყოფენ ტესტებს თანმიმდევრული, იზოლირებული მდგომარეობით.

## Setup და teardown

```text
SETUP → runs BEFORE tests to prepare the context (create objects, data, connections)
TEARDOWN → runs AFTER tests to CLEAN UP (close connections, delete data, reset state)
→ frameworks provide hooks:
  beforeEach / afterEach → before/after EACH test (fresh state per test — common)
  beforeAll / afterAll → once before/after ALL tests in a group (shared expensive setup)
```

```js
describe('UserService', () => {
  let service, db;
  beforeEach(() => {                 // fresh setup for EACH test (isolation)
    db = createTestDb();
    service = new UserService(db);
  });
  afterEach(() => db.close());        // clean up after each test

test('creates a user', () => { /* uses the fresh service/db */ });
});
```

## ფიქსტურები — ხელმეორე გამოყენებადი ტესტის მონაცემები/მდგომარეობა

```text
FIXTURES → predefined data/objects tests use (a known starting state):
  → e.g. a sample user, a set of records, a configured object
  → FACTORIES → generate test data flexibly (build objects with sensible defaults +
    overrides) — better than hardcoded data for varied scenarios
→ reduce duplication; give tests consistent, known data to work with
```

## საუკეთესო პრაქტიკა

```text
✓ Prefer beforeEach (fresh state per test) → ISOLATION (tests don't affect each other)
✓ Clean up in teardown → no leftover state causing flaky/order-dependent tests
✓ Keep setup minimal and clear; use factories for flexible test data
✓ Don't share MUTABLE state across tests (a cause of flakiness/order-dependence)
```

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

ტესტის ფიქსტურების და setup/teardown-ის გაგება ღირებული იმიტომ, რომ ისინი **აუცილებელია სუფთა, იზოლირებული, მდგრადი ტესტების დასაწერად**, ამიტომ ეს სასარგებლო პრაქტიკული ცოდნაა.

ტესტებს სჭირდებათ თანმიმდევრული საწყისი კონტექსტი (მონაცემები, ობიექტები, მდგომარეობა), და **setup/teardown** მეთოდები (hooks, რომელსაც ფრეიმვორკები იძლევა `beforeEach`/`afterEach` და `beforeAll`/`afterAll`) ამ კონტექსტს ტესტების დაწყებამდე ამზადებენ და ის კი გასუფთავებენ — აკლებს დუბლირებას (შერეული setup ერთხელ იწერება, ვიდრე ყოველ ტესტში) და უზრუნველყოფს, რომ ტესტები ცნობილი მდგომარეობით მუშაობენ.

ამ hooks-ის გაგება და როდის რომელი გამოვიყენოთ (beforeEach ფრეშ per-test მდგომარეობისთვის, beforeAll ძვირი საერთო setup-ისთვის) აუცილებელია ტესტების კარგად ორგანიზებისთვის.

**ფიქსტურების** გაგება (წინასწარ განსაზღვრული ტესტის მონაცემები და ობიექტები, რომლებიც ტესტებს ცნობილ საწყის მდგომარეობას აძლევს) და **ფაქტორების** გაგება (მოწყალილებიანი ტესტის მონაცემების წარმოქმნა გონივრული default-ებით და გადაფარვებით, უკეთესი ცხადი მონაცემებზე მრავალფეროვანი სცენარიებისთვის) ღირებულია თანმიმდევრული, მართავადი მონაცემებით ტესტების მიწოდებისთვის.

ყველაზე მნიშვნელოვანი, **საუკეთესო პრაქტიკის** გაგება დაკავშირებულია ტესტის ხარისხთან: `beforeEach`-ის ამჯობინება **ფრეშ მდგომარეობისთვის ყოველ ტესტზე** უზრუნველყოფს **იზოლაციას** (ტესტები არ მოქმედებს ერთმანეთზე — გადამწყვეტი სანდო ტესტებისთვის), **teardown-ში გასუფთავება** ხელს უშლის დარჩენილ მდგომარეობას, რომელიც flaky, წესრიგზე დამოკიდებული ტესტების გამოწვევს (flakiness-ის ხშირი წყარო), და **მუტაბელი მდგომარეობის შერჩევის არ გაზიარება ტესტების დროს** თავს იდგამს წესრიგ-დამოკიდებულებას და flakiness-ს.

ეს პრაქტიკა პირდაპირ supporting მდგომარეობის იზოლაციას და განმსაზე დინამიკას, რომელიც კარგი ტესტებს სჭირდებათ.

თუ გარკვევილი setup და cleanup სჭირდება ტესტებს, და თუ ფიქსტურები და setup/teardown (კარგად გამოყენებული, სწორი იზოლაციით და გასუფთავებით) აკლებენ დუბლირებას და უზრუნველყოფენ იზოლირებულ, დეტერმინირებულ მდგომარეობას, რომელზე საიმედო ტესტები დამოკიდებულია, ტესტის ფიქსტურების და setup/teardown-ის გაგება ღირებული, პრაქტიკულად რელევანტური ცოდნაა — მნიშვნელოვანი სუფთა, იზოლირებული, მდგრადი ტესტების დასაწერად, პირდაპირ supporting იზოლაციას და დეტერმინიზმს, რომელიც საიმედო ტესტებს flaky-დან განასხვავებს, სასარგებლო უნარი, რომელიც გამოიყენება ვირტუალურად ყოველი ტესტის სიტის ორგანიზაციაში.