كيف تضيف اختبارات للكود القديم؟

Question

Accepted Answer

**الكود القديم** (غالباً ما يكون بدون اختبارات، صعب التغيير) هو تحدٍ للاختبار — قد يحتوي على تبعيات معقدة وبدون اختبارات. إضافة الاختبارات بأمان تتضمن تقنيات مثل **اختبارات التوصيف**، **الفواصل (Seams)** لكسر التبعيات، والتحسين التدريجي، مما يتيح تغييرات أكثر أماناً.

## تحدي الكود القديم

```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.
```

## اختبارات التوصيف (تحديد السلوك الحالي)

```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.
```

## كسر التبعيات (الفواصل)

```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
```

## لماذا يهم هذا

فهم كيفية إضافة اختبارات للكود القديم هو معرفة قيمة على مستوى كبار الهندسيين لأن **معظم العمل في العالم الحقيقي يتضمن كوداً موجوداً بالفعل، غالباً بدون اختبارات**، وتحسينه بأمان هو تحدٍ شائع وهام، لذلك فهو ذو صلة عملية.

الكود القديم (بدون اختبارات، مشدود الاقتران، صعب التغيير) يقدم مشكلة حقيقية **للدجاجة والبيضة**: لتغييره بأمان تحتاج اختبارات، لكن من الصعب اختباره (تبعيات معقدة، لم يصمم للاختبار) — وتغيير كود بدون اختبارات خطر لأنك لا تستطيع معرفة ما إذا أفسدت شيئاً.

فهم التقنيات لمعالجة هذا هو معرفة عملية قيمة. **اختبارات التوصيف** (التقاط السلوك **الحالي** للكود كما هو، التأكيد على ما يفعله فعلاً بدلاً من ما يجب أن يفعل — حتى لو لم يكن مفهوماً بالكامل) توفر **شبكة أمان** تتيح لك إعادة البناء والتغيير بثقة بأن السلوك الموجود محفوظ — تقنية أساسية للعمل مع كود لا تفهمه بالكامل.

فهم **كسر التبعيات عبر الفواصل** (إيجاد أو إنشاء أماكن لاستبدال التبعيات، استخدام عمليات إعادة بناء آمنة صغيرة لجعل الكود المعقد قابلاً للاختبار — التقنيات من عمل مايكل فذرز على الكود القديم) ضروري للحصول على كود يصعب اختباره تحت الاختبار.

فهم **النهج التدريجي** — إضافة اختبارات حول الكود قبل تغييره (شبكة أمان للتغيير)، التركيز على المناطق التي يتم تغييرها أو عالية المخاطر/القيمة (ليس المشروع بأكمله دفعة واحدة)، والتحسين بشكل تدريجي (قاعدة الكشاف) — يعكس الطريقة العملية والواقعية لتحسين الأنظمة القديمة بمرور الوقت.

نظراً لأن معظم التطوير في العالم الحقيقي يتضمن كوداً قديماً موجوداً بالفعل، غالباً بدون اختبارات يجب تغييره بأمان (موقف شائع وتحديٍ صعب)، وبما أن فهم التقنيات (اختبارات التوصيف لشبكة أمان، الفواصل لكسر التبعيات، التحسين التدريجي) يمكّن من فعل هذا، فإن فهم كيفية إضافة اختبارات للكود القديم هو معرفة قيمة على مستوى كبار الهندسيين — ذو صلة عملية للواقع الشائع للعمل مع كود موجود بدون اختبارات، يعكس الخبرة والتقنيات المطلوبة لتحسين الأنظمة القديمة بأمان، كفاءة مهمة لمهندسي كبار الذين غالباً ما يجب عليهم جعل الكود بدون اختبارات أكثر أماناً للتغيير.