المهارات test-driven-development
📦

test-driven-development

آمن

تطبيق التطوير القائم على الاختبار

متاح أيضًا من: Cycleaddict,davila7,DMJGilbert,DYAI2025,Cygnusfear,CodingCossack,obra

كتابة الاختبارات بعد كتابة الكود تؤدي إلى ثقة خاطئة وتخطي حالات الحافة. هذه المهارة تفرض انضباط TDD: اكتب اختبارًا فاشلًا أولاً، ثم نفّذ الحد الأدنى من الكود لاجتيازه.

يدعم: Claude Codex Code(CC)
🥉 74 برونزي
1

تنزيل ZIP المهارة

2

رفع في Claude

اذهب إلى Settings → Capabilities → Skills → Upload skill

3

فعّل وابدأ الاستخدام

اختبرها

استخدام "test-driven-development". أحتاج إلى إضافة دالة تتحقق من صحة عناوين البريد الإلكتروني

النتيجة المتوقعة:

لنبدأ بـ TDD. أولاً، سأكتب اختبارًا فاشلًا:

```typescript
test('rejects invalid email', () => {
expect(validateEmail('invalid')).toBe(false);
});
```

الآن سأشغّل هذا الاختبار للتأكد من فشله...

استخدام "test-driven-development". يجب أن تتعامل دالة تسجيل الدخول مع كلمات المرور الخاطئة

النتيجة المتوقعة:

اتباع TDD، أولاً الاختبار:

```typescript
test('rejects wrong password', async () => {
const result = await login('user@test.com', 'wrongpass');
expect(result.success).toBe(false);
expect(result.error).toBe('Invalid credentials');
});
```

تشغيل الاختبار للتحقق من فشله...

التدقيق الأمني

آمن
v1 • 2/24/2026

This is a legitimate Test-Driven Development educational skill. The static analyzer detected 73 potential issues, but after semantic evaluation, all findings are FALSE POSITIVES. The 'external_commands' detections are markdown code block delimiters (backticks) in documentation, not actual shell execution. The 'weak cryptographic algorithm' and 'network reconnaissance' detections are similarly false positives triggered by keywords in educational context. No executable malicious code exists in this skill.

2
الملفات التي تم فحصها
672
الأسطر التي تم تحليلها
1
النتائج
1
إجمالي عمليات التدقيق
مشكلات متوسطة المخاطر (1)
Markdown Code Block Delimiters Flagged as Shell Execution
The static scanner detected 'Ruby/shell backtick execution' patterns in markdown files. These are FALSE POSITIVES - the backticks are markdown code fence delimiters (```typescript, ```bash) used for syntax highlighting in documentation, not runtime command execution. The skill is educational content about TDD methodology with no actual shell commands being executed.
تم تدقيقه بواسطة: claude

درجة الجودة

38
الهندسة المعمارية
100
قابلية الصيانة
87
المحتوى
50
المجتمع
100
الأمان
91
الامتثال للمواصفات

ماذا يمكنك بناءه

تنفيذ ميزة جديدة

عند بناء ميزة جديدة، اكتب الاختبار أولاً الذي يحدد السلوك المتوقع، راقب فشله، ثم نفّذ الكود لاجتيازه

سير عمل إصلاح الأخطاء

عند إصلاح خطأ، اكتب أولاً اختبارًا يعيد إنتاج الخطأ، راقب فشله، ثم أصلح الكود لاجتياز الاختبار

إعادة الهيكلة بثقة

قبل إعادة الهيكلة، تأكد من وجود اختبارات. الاختبارات تتحقق من بقاء السلوك صحيحًا بعد تغييرات الكود

جرّب هذه الموجهات

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

أفضل الممارسات

  • اكتب اختبارًا واحدًا في كل مرة - ركّز على سلوك واحد
  • سمّ الاختبارات حسب السلوك الذي تتحقق منه، وليس حسب ما يتم اختباره
  • راقب دائمًا فشل الاختبار قبل كتابة التنفيذ
  • حافظ على التنفيذ الأدنى - اجتز الاختبار الحالي فقط

تجنب

  • كتابة كود التنفيذ قبل الاختبارات (ثم 'تكييف' الاختبارات)
  • الإبقاء على كود التنفيذ الفاشل كـ 'مرجع' أثناء كتابة الاختبارات
  • اختبارات تجتاز فورًا - لا تثبت شيئًا
  • اختبار سلوك المحاكاة بدلاً من سلوك المكون الحقيقي

الأسئلة المتكررة

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

تفاصيل المطور

بنية الملفات