السلام عليكم.

اسمع و اقرء الكثير من الكلام عن :
- Depandancy injection
- unite test
و عن العلاقة الموجدة بينهما، و كيف انهما يسهلان عملية متابعة و تطوير المشاريع.

حاولت ان استوعب الفكرة، لكني احتاج الى بعض الامثلة...هل من مساعدة من فضلكم؟

شكرا جزيلا

 
وعليكم السلام أنس. الموضوع سهل جداً. أولاً، سنتحدث قليلاً عن اختبار الوحدات (unit testing). هذا النوع من الاختبارات مفيد للتحقق من سلامة مكونات البرنامج كل على حدة. الفكرة أننا لو تأكدنا أن كل مكون يعمل بشكل صحيح بحد ذاته، فإننا نكون قد تخلصنا من كمية كبيرة من الأخطاء المحتملة.

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

- رسم أشكال شبحية.
- تحريك هياكل شخصيات.
- تشغيل أصوات.
- ذكاء صناعي.
- ... الخ.

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

كما ترى، هي عملية مضنية، لكنها تخفف عن المبرمج الكثير من الجهد والفضائح 😄

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

طبعاً هذه الفكرة تتطلب بناء المكونات بطريقة الواجهات (interfaces) وهو أمر ليس بالسهل، ويحتاج لبعض الهندسة. لكن إيجابياته كبيرة. إن نجحنا في بناء المحرك على هذا المبدأ، نستطيع استبدال أي من مكوناته بمكون "كذابي" لأغراض الاختبار المؤتمت. هذا الأسلوب هو ما يصطلح عليه "حقن الاعتماد" (Dependency Injection). أي أنك تحقن بديلاً للمكون المُــعتــَمـَـد عليه من قبل الوحدة الخاضعة للاختبار.


أرجو أن تكون قد وصلت الفكرة ☺

أخي وسام ، أسلوبك رائع ومميز في الشرح ، استمتعت بالقراءة☺ .. شكرا لك .