كيف تكتب اختبارات أفضل بالذكاء الاصطناعي

معظم المطورين يعرفون أنه يجب عليهم كتابة المزيد من الاختبارات. المشكلة ليست الدافعية — إنها الوقت. كتابة اختبارات جيدة بطيئة، وكتابة اختبارات سيئة سهلة. الاختبارات بمساعدة الذكاء الاصطناعي مع Claude Code تعكس هذه المعادلة: يمكنك كتابة مجموعة اختبار شاملة في الوقت الذي كان يستغرقه كتابة بضعة اختبارات وحدة هشة.

مهارة test-master تجعل Claude خبيراً في استراتيجية الاختبار، وليس فقط في بناء جملة الاختبار.

---

لماذا تفشل معظم الاختبارات في منع الأخطاء

قبل الدخول في كيفية كتابة اختبارات أفضل، يستحق الأمر فهم لماذا لا تعمل معظم الاختبارات بالشكل المطلوب.

أخطاء الاختبار الشائعة:

• اختبار تفاصيل التنفيذ بدلاً من السلوك
• اختبار المسار السعيد فقط
• محاكاة كل شيء وعدم اختبار أي شيء حقيقي
• كتابة الاختبارات بعد الوقعة التي تؤكد السلوك الحالي بدلاً من تحديد السلوك المقصود
• مقاييس التغطية التي تشجع الكمية على الجودة

مهارة test-master مدربة على تجنب جميع هذه الأنماط. عندما تطلب من Claude كتابة اختبارات، يسأل "ماذا يفترض أن يفعل هذا الكود؟" قبل سؤال "كيف يعمل هذا الكود؟"

---

سير عمل TDD مع الذكاء الاصطناعي

التطوير المدفوع بالاختبارات كان دائماً سليماً من الناحية النظرية لكن صعباً في الممارسة — كتابة الاختبارات أولاً تتطلب انضباطاً عندما يمكنك رؤية التنفيذ أمامك مباشرة. الذكاء الاصطناعي يغير هذه الديناميكية.

TDD أولاً بالذكاء الاصطناعي يبدو هكذا:

1. صف الميزة لـClaude بلغة بسيطة
2. Claude يكتب الاختبارات التي تحدد السلوك المتوقع
3. تشغّل الاختبارات — كلها تفشل (أحمر)
4. Claude يكتب التنفيذ لجعل الاختبارات تنجح (أخضر)
5. Claude يُعيد الهيكلة لتنظيف التنفيذ مع إبقاء الاختبارات خضراء

هذا يعمل لأن Claude يستطيع الاحتفاظ بالمواصفات في الذهن أثناء كتابة الاختبارات والتنفيذ معاً. لا تحتاج لتبديل السياق — فقط صف ما تريد.

مثال:

"اكتب اختبارات لدالة `createUser`. يجب أن:
- تقبل الاسم والبريد الإلكتروني وكلمة المرور
- تتحقق من صيغة البريد الإلكتروني
- تشفر كلمة المرور قبل التخزين
- تعيد المستخدم المُنشأ بدون hash كلمة المرور
- ترمي UserExistsError إذا كان البريد الإلكتروني مأخوذاً"

يكتب Claude اختبارات تفحص جميع هذه السلوكيات، بما في ذلك الحالات الحدية التي ربما لم تفكر فيها — سلاسل فارغة، محاولات حقن SQL في حقل الاسم، تسجيلات مكررة متزامنة.

---

اختبار الوحدة: ماذا تختبر وماذا تتجاوز

ليس كل شيء يحتاج اختبار وحدة. مهارة test-master تساعدك في تحديد ما يستحق الاختبار:

اختبر هذه:

• الدوال النقية ذات المدخلات والمخرجات الواضحة
• منطق العمل ذو التفرعات المتعددة
• دوال التحقق
• تحويلات البيانات
• مسارات معالجة الأخطاء

تجاوز هذه (اختبر على مستوى أعلى):

• الـ getters والـ setters البسيطة
• الوظائف التي يوفرها الإطار
• داخليات المكتبات الخارجية
• الأغلفة ذات السطر الواحد

مثال على اختبار وحدة منظم جيداً:

describe('calculateDiscount', () => {
  it('يطبق خصماً بالنسبة المئوية على السعر الأساسي', () => {
    expect(calculateDiscount(100, { type: 'percentage', value: 20 })).toBe(80);
  });

  it('يطبق خصماً بمبلغ ثابت', () => {
    expect(calculateDiscount(100, { type: 'fixed', value: 15 })).toBe(85);
  });

  it('لا يعيد أبداً سعراً سالباً', () => {
    expect(calculateDiscount(10, { type: 'fixed', value: 50 })).toBe(0);
  });

  it('يرمي لنوع خصم غير صالح', () => {
    expect(() => calculateDiscount(100, { type: 'invalid', value: 10 }))
      .toThrow('Unknown discount type');
  });
});

لاحظ: كل اختبار له تأكيد واحد (مثالياً)، يختبر السلوك وليس التنفيذ، ويتضمن الحالات الحدية.

---

اختبار التكامل: أكثر أنواع الاختبار إهمالاً

اختبارات الوحدة تختبر الدوال بمعزل. اختبارات E2E تختبر التطبيق الكامل. اختبارات التكامل تختبر نقاط الالتقاء — حيث تتصل أجزاء مختلفة من نظامك. هذه أكثر الاختبارات قيمة والأكثر إهمالاً.

مع Claude Code، يصبح اختبار التكامل أسهل:

"اكتب اختبارات تكامل لـ endpoint واجهة برمجة تسجيل المستخدم.
اختبر دورة الطلب/الاستجابة الكاملة بما في ذلك تفاعلات قاعدة البيانات.
استخدم قاعدة بيانات اختبار تُعاد تهيئتها بين الاختبارات."

سيكتب Claude اختبارات تُشغّل قاعدة بيانات اختبار وتستدعي معالج API الفعلي وتؤكد على حالة الاستجابة والمحتوى وتتحقق من حالة قاعدة البيانات بعد العملية وتنظف بعد كل اختبار. هذا يكتشف فئة كاملة من الأخطاء تفوتها اختبارات الوحدة.

---

اختبار E2E مع Playwright

اختبارات end-to-end مع Playwright تختبر تطبيقك كما سيستخدمه المستخدم. مهارة test-master تعرف Playwright بعمق — نماذج الصفحة، المثبتات، اعتراض الشبكة، والاختبار المرئي.

اختبار E2E كامل مع Claude:

"اكتب اختبار Playwright لتدفق الدفع:
1. أضف منتجاً إلى العربة
2. انتقل إلى الدفع
3. أدخل تفاصيل الشحن
4. أدخل دفعة اختبار (بطاقة: 4242424242424242)
5. تحقق أن صفحة تأكيد الطلب تعرض تفاصيل الطلب الصحيحة"

يولد Claude اختباراً سليماً مع نموذج كائن الصفحة للصيانة، واستراتيجيات انتظار مناسبة، وتأكيدات طلبات الشبكة، ولقطة شاشة مرئية عند الفشل، ودعم التنفيذ المتوازي.

---

استراتيجيات المحاكاة

المحاكاة هي المكان الذي تسوء فيه الاختبارات في أغلب الأحيان. محاكاة قليلة جداً والاختبارات بطيئة وغير مستقرة. كثير جداً ولا تختبر أي شيء حقيقي.

مهارة test-master تطبق هذه القواعد:

1. احْكِ عند الحدود — احكِ عميل HTTP، وليس الدالة التي تستدعيه
2. لا تحكِ ما تمتلكه — استخدم تنفيذات حقيقية لكودك الخاص
3. احكِ للسرعة، وليس للراحة — احكِ فقط الأشياء التي ستبطئ الاختبارات
4. تحقق من المحاكيات — أكد أن المحاكيات استُدعيت بالحجج الصحيحة

---

تحليل التغطية

مقاييس التغطية مفيدة لكنها مضللة إذا لم تُفهم. مهارة test-master تساعدك في تفسير تقارير التغطية وتحديد ما يحتاج فعلاً لمزيد من الاختبارات.

حقيقة التغطية:

• تغطية 100% لا تعني خالية من الأخطاء
• الكود غير المغطى مؤكداً اختُبر بشكل غير كافٍ
• أهم المسارات للتغطية هي مسارات الخطأ، وليس المسارات السعيدة
• تغطية الفروع أكثر أهمية من تغطية الأسطر

عندما يحلل Claude تقرير تغطيتك، لا يشير فقط للأسطر غير المغطاة — يسأل "هل يستحق هذا الكود غير المغطى الاختبار؟" أحياناً الإجابة لا.

---

أخطاء الاختبار الشائعة (وكيف تتجنبها)

الخطأ 1: اختبار التنفيذ، وليس السلوك

// سيئ: يختبر أن الدالة تستدعي طريقة داخلية محددة
expect(spy).toHaveBeenCalledWith('internal_helper');

// جيد: يختبر أن المستخدم يحصل على النتيجة الصحيحة
expect(result.user.name).toBe('Alice');

الخطأ 2: تأكيدات محددة بشكل مفرط

// سيئ: ينكسر إذا أضفت حقلاً جديداً للاستجابة
expect(response).toEqual({ id: 1, name: 'Alice', email: 'alice@example.com' });

// جيد: يؤكد على ما يهم
expect(response.name).toBe('Alice');
expect(response).not.toHaveProperty('password');

الخطأ 3: اختبارات لا تختبر الفشل

// دائماً أضف اختباراً واحداً على الأقل لما يحدث عندما تسوء الأمور
it('يعيد null لمستخدم غير موجود', async () => {
  const result = await getUser('nonexistent-id');
  expect(result).toBeNull();
});

---

بناء مجموعة اختبار كاملة

مجموعة اختبار متوازنة لتطبيق ويب تبدو هكذا:

• 70% اختبارات وحدة — سريعة ومركزة تختبر دوالاً فردية
• 20% اختبارات تكامل — تختبر تفاعلات المكونات، خاصة مسارات API وعمليات قاعدة البيانات
• 10% اختبارات E2E — تختبر رحلات المستخدم الحرجة من البداية للنهاية

مهارة test-master تساعدك في بناء هذه الهرم بكفاءة. عندما تطلب من Claude "أضف اختبارات لهذه الميزة"، يفكر في الهرم الكامل ويكتب المستوى الصحيح من الاختبار لكل جزء.

---

البدء

أسرع طريقة لبدء الاختبار بشكل أفضل هي وصف ميزة على وشك بنائها وطلب من Claude (مع تفعيل test-master) كتابة الاختبارات أولاً. شغّلها، شاهدها تفشل، ثم اطلب من Claude تنفيذ الميزة. ستنتهي بتغطية اختبار أكبر وكود أفضل هيكلة مما لو بنيته بالترتيب العكسي.

مهارة test-master جزء من مكتبة SuperSkills — 139 مهارة تجعل Claude Code خبيراً في مجالك.

مستعد لكتابة اختبارات تكتشف الأخطاء فعلاً؟ اطلع على مكتبة المهارات الكاملة في /#pricing.