test-driven-development
أتقن سير عمل التطوير القائم على الاختبار
متاح أيضًا من: ZhanlinCui,DMJGilbert,Cycleaddict,davila7,DYAI2025,CodingCossack,Cygnusfear,obra
كتابة الاختبارات بعد كتابة الكود لا تقدم أي دليل على أنها تختبر شيئًا فعليًا. هذه المهارة تفرض دورة Red-Green-Refactor حيث يجب أن يفشل كل اختبار قبل التنفيذ، مما يضمن أن الاختبارات تتحقق من السلوك الفعلي.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "test-driven-development". Implement a function that retries failed operations 3 times
النتيجة المتوقعة:
- الخطوة 1 (RED): اكتب اختبار 'retries failed operations 3 times'
- الخطوة 2: شغّل الاختبار - تحقق من فشله لأن منطق إعادة المحاولة غير موجود
- الخطوة 3 (GREEN): نفذ حلقة إعادة محاولة حد أدنى
- الخطوة 4: شغّل الاختبار - تحقق من نجاحه
- الخطوة 5 (REFACTOR): استخرج منطق إعادة المحاولة إذا لزم الأمر
استخدام "test-driven-development". Bug: Empty email accepted in form
النتيجة المتوقعة:
- RED: test('rejects empty email') - expect error 'Email required'
- تحقق: يفشل الاختبار - النموذج يقبل حاليًا البريد الإلكتروني الفارغ
- GREEN: أضف تحققًا من صحة البريد الإلكتروني الفارغ
- تحقق: ينجح الاختبار، لا توجد تراجعات
- النتيجة: تم إصلاح الخطأ مع اختبار يمنع التراجع
التدقيق الأمني
آمنThis skill contains only markdown documentation explaining test-driven development methodology. All 57 static analyzer findings for external_commands are false positives - the detected backticks are markdown code fences (```) used for syntax highlighting, not Ruby shell execution. The 6 cryptographic algorithm findings and reconnaissance detections are also false positives from pattern matching on documentation text. No executable code, network calls, or filesystem operations exist in this skill.
درجة الجودة
ماذا يمكنك بناءه
تطوير ميزة جديدة
استخدم TDD عند تنفيذ ميزات جديدة لضمان أن كل دالة لديها اختبارات مقابلة تثبت السلوك الصحيح قبل الالتزام
إصلاح خطأ مع منع التراجع
اكتب اختبارًا فاشلاً يعيد إنتاج الخطأ أولاً، ثم نفذ الإصلاح، مما يضمن عدم عودة الخطأ
إعادة الهيكلة بثقة
استخدم مجموعة الاختبارات الموجودة للتحقق من بقاء السلوك دون تغيير أثناء إعادة هيكلة الكود أو تحسينه
جرّب هذه الموجهات
I need to implement [feature]. Help me write a failing test first that describes the expected behavior, then guide me through Red-Green-Refactor.
Bug: [describe bug]. Help me write a test that reproduces this bug (should fail), then implement the minimal fix to make it pass.
Review my test for [function]. Does it test real behavior or mock behavior? Is the test name clear? Does it test one thing?
I'm about to [action]. Check if this violates TDD principles. Am I testing mock behavior? Adding test-only code? Mocking without understanding?
أفضل الممارسات
- راقب دائمًا فشل الاختبار قبل التنفيذ - هذا يثبت أن الاختبار يختبر شيئًا فعليًا
- اكتب الحد الأدنى من الكود لاجتياز الاختبار - لا ميزات إضافية، لا هندسة مفرطة
- احذف كود التنفيذ إذا تجاوزت دورة TDD وابدأ من جديد بالاختبارات أولاً
تجنب
- كتابة كود التنفيذ قبل وجود الاختبار
- اختبار سلوك الـ mock بدلاً من سلوك الكود الفعلي
- إضافة طرق خاصة بالاختبار فقط إلى فئات الإنتاج
الأسئلة المتكررة
ماذا لو كتبت كود التنفيذ بالفعل؟
هل يمكنني كتابة الاختبارات بعد التنفيذ؟
ماذا لو كان الكود بسيطًا جدًا للاختبار؟
كيف أتعامل مع الكود الموجود بدون اختبارات؟
ماذا لو كان إعداد الاختبار معقدًا جدًا؟
متى يمكنني تخطي TDD؟
تفاصيل المطور
المؤلف
sickn33الترخيص
MIT
المستودع
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/test-driven-developmentمرجع
main
بنية الملفات