tdd-workflow
تنفيذ سير عمل التطوير القائم على الاختبار (TDD)
متاح أيضًا من: DoubleslashSE
يضيع المطورون الوقت في تصحيح الأخطاء بدون اختبارات. تفرض هذه المهارة دورة RED-GREEN-REFACTOR لبناء برمجيات موثوقة بثقة.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "tdd-workflow". تنفيذ دالة للتحقق من صحة عناوين البريد الإلكتروني
النتيجة المتوقعة:
- طور RED: تم إنشاء اختبار 'should accept valid email format' - الاختبار فشل (لا يوجد تنفيذ بعد)
- طور GREEN: تم تنفيذ تحقق regex الأدنى - الاختبار نجح
- طور REFACTOR: تم استخراج منطق التحقق إلى دالة منفصلة، تحسين رسائل الخطأ
استخدام "tdd-workflow". إصلاح استثناء المؤشر الفارغ في بحث المستخدم
النتيجة المتوقعة:
- طور RED: الاختبار يعيد إنتاج استثناء المؤشر الفارغ - تم تأكيد الفشل
- طور GREEN: تمت إضافة فحص null قبل الوصول إلى خصائص المستخدم - الاختبار نجح
- طور REFACTOR: تم إنشاء دالة مساعدة آمنة للـ null قابلة لإعادة الاستخدام مستخدمة في جميع أنحاء قاعدة الكود
التدقيق الأمني
آمنAll static analysis findings are false positives. The arrow character (→) was misidentified as shell backtick execution. References to 'crypto' and 'reconnaissance' are pattern matching errors on plain text documentation. This is a safe TDD methodology guide. External commands are legitimately used for running test suites.
عوامل الخطر
⚙️ الأوامر الخارجية (1)
درجة الجودة
ماذا يمكنك بناءه
تطوير ميزة جديدة
بناء ميزات موثوقة عن طريق كتابة الاختبارات أولاً، ثم تنفيذ الحد الأدنى من الكود لاجتياز كل اختبار.
إصلاح الخطأ مع حماية التراجع
اكتب اختباراً يعيد إنتاج الخطأ، أصلحه، ثم أعد الهيكلة بثقة بأن الخطأ سيبقى مُصلحاً.
تحسين جودة كود الفريق
استخدم نمط TDD متعدد الوكلاء حيث يكتب وكلاء مختلفون الاختبارات، وينفذون الكود، ويعيدون الهيكلة.
جرّب هذه الموجهات
أريد تنفيذ دالة تقوم بـ [describe behavior]. اكتب اختباراً فاشلاً أولاً متبعاً طور RED من TDD. يجب أن يصف الاختبار السلوك المتوقع بوضوح.
لننفذ [feature] باستخدام TDD. الخطوة 1: اكتب اختباراً فاشلاً. الخطوة 2: اكتب الحد الأدنى من الكود للاجتياز. الخطوة 3: أعد الهيكلة للوضوح. إرشادي خلال كل طور.
راجع هذا الاختبار وأعد هيكليته باستخدام نمط AAA (Arrange, Act, Assert). حدد البيانات التي تحتاج إعداداً، وما الكود الذي يُنفذ، وما النتيجة المراد التحقق منها.
شغّل جلسة TDD متعددة الوكلاء لـ [feature]. الوكيل A يكتب الاختبار الفاشل، الوكيل B ينفذ للاجتياز، الوكيل C يعيد الهيكلة. نسّق عمليات التسليم بين الأطوار.
أفضل الممارسات
- راقب دائماً فشل الاختبار قبل كتابة كود التنفيذ - هذا يتحقق من عمل الاختبار
- اكتب تأكيداً واحداً لكل اختبار لعزل الإخفاقات وتوضيح النية
- قم بعمل commit بعد كل دورة كاملة من RED-GREEN-REFACTOR للحفاظ على تغييرات صغيرة قابلة للمراجعة
تجنب
- كتابة الكود قبل فشل الاختبار - يُفقد هدف TDD وغالباً يعني أنك لا تفهم المتطلبات
- اختبار تفاصيل التنفيذ مثل أسماء الدوال الخاصة - يجب أن تتحقق الاختبارات من السلوك، وليس البنية الداخلية
- تأكيدات متعددة لكل اختبار - يجعل الإخفاقات غامضة وينتهك مبدأ المسؤولية الواحدة