როგორ დაამატებთ ტესტებს legacy კოდს?

Question

Accepted Answer

**Legacy კოდი** (ხშირად არატესტირებული, ცვლილებისთვის რთული კოდი) გამოწვევა წარმოადგენს ტესტირებისთვის — შეიძლება ჰქონდეს დაბნეული dependencies და არ აქვს ტესტები. ტესტების უსაფრთხოდ დამატება მოიცავს ტექნიკებს, როგორიცაა **characterization ტესტები**, **seams** dependencies-ების გასაწყვეტად, და ნაზი გაუმჯობესება, რაც უფრთხესი ცვლილებების საშუალებას იძლევა.

## Legacy კოდის გამოწვევა

```text
Legacy code is often: untested, tightly coupled, hard to understand, risky to change:
  → no tests → changing it is dangerous (you can't tell if you broke something)
  → hard to test → dependencies are tangled (can't isolate units); not designed for testing
→ a chicken-and-egg problem: to change safely you need tests, but it's hard to test.
```

## Characterization ტესტები (დღემდე ამჟამინდელი ქცევის ფიქსირება)

```text
CHARACTERIZATION (golden master) tests → capture the code's CURRENT behavior as-is
  (even if you don't fully understand it / it has bugs):
  → write tests asserting what it ACTUALLY does now → a SAFETY NET
  → then you can refactor/change with confidence that behavior is preserved
→ Don't assert what it SHOULD do — assert what it DOES, to protect against regressions.
```

## Dependencies-ების გასაწყვეტი (seams)

```text
To isolate hard-to-test code, find/create SEAMS (places to substitute dependencies):
  → extract dependencies behind interfaces; inject them; use the smallest safe refactors
    to make code testable (Michael Feathers' techniques)
  → carefully break dependencies so you can get the code under test, then test, then refactor
```

## ნაზი მიდგომა

```text
✓ Add tests AROUND code BEFORE changing it (a safety net for the change)
✓ Focus on areas you're CHANGING / high-risk / high-value (not the whole codebase at once)
✓ Improve incrementally — leave code a bit better each time (the "boy scout rule")
✓ Use characterization tests to capture behavior, then refactor toward testability
```

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

გაგება, თუ როგორ დაამატოთ ტესტები legacy კოდს, ღირებული უფროსი დონის ცოდნაა, რადგან **უმეტეს რეალური სამუშაოს მოიცავს არსებული, ხშირად არატესტირებული კოდი**, და მისი უსაფრთხო გაუმჯობესება ხშირი, მნიშვნელოვანი გამოწვევაა, ამიტომ პრაქტიკულად რელევანტურია.

Legacy კოდი (არატესტირებული, მჭიდროდ შეკრული, ცვლილებისთვის რთული) წარმოადგენს რეალურ **წიწილა-და-კვერცხის პრობლემას**: მისი უსაფრთხოდ ცვლილებისთვის გჭირდებათ ტესტები, მაგრამ ტესტირება რთულია (დაბნეული dependencies, არ არის დიზაინირებული ტესტირებისთვის) — და არატესტირებული კოდის ცვლილება საშიში, რადგან ვერ უთითებთ თუ რამე დაარღვიეთ.

ამ პრობლემის გადასაჭრელი ტექნიკების გაგება ღირებული პრაქტიკული ცოდნაა. **Characterization ტესტები** (კოდის *დღემდელი* ქცევის ჩაჭერა, ისე როგორც არის, მოთხოვნილებების დადასტურება რა ის რეალურად აკეთებს ვიდრე რა უნდა აკეთოს — თუნდაც სრულად გაუგებრად) უზრუნველყოფს **უსაფრთხოების ქსელს**, რომელიც დაგაშვებთ refactor-ს და ცვლილებას確信, რომ არსებული ქცევა შენახულია — მნიშვნელოვანი ტექნიკა კოდთან მუშაობისთვის, რომელიც სრულად არ ესმით.

გაგება **dependencies-ების გასაწყვეტი seams-ის მეშვეობით** (ადგილების პოვნა ან შექმნა dependencies-ების ჩანაცვლებისთვის, მინიმალური უსაფრთხო refactor-ის გამოყენება დაბნეული კოდის ტესტირებად — მიხეილ ფეზერსის legacy კოდზე გამოკვლევების ტექნიკები) აუცილებელია რთული ტესტირებადი კოდის ტესტის ქვეშ მოსაყვანად.

გაგება **ნაზი მიდგომის** — ტესტების დამატება კოდის გარშემო ის ცვლილებამდე (უსაფრთხოების ქსელი ცვლილებისთვის), ფოკუსირება იმ ადგილებზე, რომლებიც იცვლება ან მაღალი რისკი/მაღალი ღირებულება (არა მთელი codebase ერთდროულად), და ნაზი გაუმჯობესება (ბიჭის scout წესი) — ასახავს პრაგმატულ, რეალისტურ გზას legacy სისტემების დროთა განმავლობაში გაუმჯობესებისთვის.

ვინაიდან უმეტეს რეალური განვითარებისას მოიცავს არსებულ, ხშირად არატესტირებულ legacy კოდს, რომელიც უნდა იყოს უსაფრთხოდ შეცვლილი (ხშირი, რთული ვითარება), და ვინაიდან ტექნიკების გაგება (characterization ტესტები უსაფრთხოების ქსელისთვის, seams dependencies-ების გასაწყვეტად, ნაზი გაუმჯობესება) ამ კეთების საშუანებას იძლევა, გაგება, თუ როგორ დაამატოთ ტესტები legacy კოდს, ღირებული უფროსი დონის ცოდნაა — პრაქტიკულად რელევანტური არსებული არატესტირებული კოდთან მუშაობის საერთო რეალობისთვის, ასახავს გამოცდილებას და ტექნიკებს, რომლებიც საჭიროა legacy სისტემების უსაფრთხოდ გაუმჯობესებისთვის, უფროსი ინჟინრების მნიშვნელოვანი კომპეტენცია, ხშირად უნდა გახადოს არატესტირებული კოდი უფრთხესი ცვლილებისთვის.