---
title: "التطوير المدفوع بالاختبارات"
type: "architectural-pattern"
slug: "test-driven-development"
url: "http://localhost:3000/ar/architectural-patterns/test-driven-development.md"
also_known_as: "TDD, Red-Green-Refactor"
description: "منهجية تطوير تكتب فيها اختباراً فاشلاً قبل الكود الذي يجتازه، ثم تُعيد الهيكلة — مدعاً الاختباراتِ تقود التصميم في دورات قصيرة ومتسارعة."
languages: ["python"]
---
# التطوير المدفوع بالاختبارات

_Also known as: TDD, Red-Green-Refactor_

> منهجية تطوير تكتب فيها اختباراً فاشلاً قبل الكود الذي يجتازه، ثم تُعيد الهيكلة — مدعاً الاختباراتِ تقود التصميم في دورات قصيرة ومتسارعة.

## Intent

قيادة التصميم والتحقق من صحة الكود بكتابة اختبار فاشل لكل جزء صغير من السلوك _قبل_ كتابة الكود الذي يُرضيه، ثم تحسين التصميم بينما تحرسك الاختبارات.

## Problem

الكود المكتوب بدون اختبارات محفوف بالمخاطر عند التعديل: لا توجد طريقة سريعة لمعرفة ما إذا كان التعديل قد كسر شيئاً. الاختبارات المكتوبة _بعد_ الواقعة تميل إلى أن تكون سطحية، مُشكَّلة لتناسب كوداً قد يكون صعب الاختبار أصلاً، وتؤثر نادراً في التصميم.

بدون قوة دافعة، تميل التصاميم إلى أن تصبح متشابكة وصعبة الاختبار المعزول.

## Solution

اعمل في دورة **أحمر-أخضر-إعادة هيكلة** قصيرة:

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

كرّر في حلقات تمتد لدقائق. لأن الاختبارات تأتي أولاً، يكون الكود قابلاً للاختبار بطبيعته وتوثّق المجموعة السلوك المقصود.

## Structure

* **الدورة** — أحمر → أخضر → إعادة هيكلة، تتكرر باستمرار.
* **قائمة الاختبارات** — القائمة الجارية للسلوكيات التي لا تزال بحاجة إلى تغطية.
* **ترتيب-تشغيل-تأكيد** — هيكل اختبار الوحدة المُركَّز.
* **الوحدة قيد الاختبار** — الشريحة الصغيرة من السلوك التي يُثبّتها كل اختبار.

## Applicability

* استخدمه للكود الذي يحتوي على **منطق متفرع** وللكود طويل الأمد الذي يتغير كثيراً.
* ذو قيمة خاصة حيث تكون حلقة التغذية الراجعة السريعة والحماية من الانحدار ضرورية.
* **أقل ملاءمة** للنماذج الأولية أو أعمال واجهة المستخدم الاستكشافية حيث التصميم لا يزال في طور التشكّل.

## How to Implement

1. اختر السلوك الصغير التالي من قائمة اختباراتك.
2. اكتب اختباراً يتحقق منه، وشغّل المجموعة لتراه يفشل (أحمر).
3. اكتب الحد الأدنى من الكود اللازم للنجاح؛ شغّل المجموعة (أخضر).
4. أعد هيكلة كود الإنتاج وكود الاختبار مع إبقاء المجموعة خضراء.
5. كرّر، مضيفاً سلوكيات إلى القائمة كلما اكتشفتها.

## Pros

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

## Cons

* وتيرة أولية أبطأ ومنحنى تعلم حقيقي.
* قد يُركّز على الوحدات المعزولة ويفوته ثغرات التكامل.
* الاختبارات هي كود أيضاً — يجب صيانتها وإعادة هيكلتها.
* ليست بديلاً عن الاختبار الاستكشافي أو التكاملي أو الشامل.
## Relations

**Related patterns**

- [التطوير المدفوع بالمواصفات](/ar/architectural-patterns/spec-driven-development.md)

## Code Examples

### python

```python
# أحمر: اكتب الاختبار الفاشل أولاً.
def test_slugify_lowercases_and_hyphenates():
    assert slugify('Hello World') == 'hello-world'

# أخضر: أبسط كود يجتاز الاختبار.
def slugify(text: str) -> str:
    return text.lower().replace(' ', '-')

# أعِد الهيكلة لاحقاً (مثلاً: إزالة علامات الترقيم) مع الاختبار كشبكة أمان.
```