عنوان المقال: “إستراتيجيات اختبار الوحدات وتحديد نسبة التغطية المثلى للشيفرة”
الوحدات البرمجية وتحليل نسبة تغطية الشيفرة يظلان من المواضيع ذات القليل من المعلومات في سياق تجارب العالم الحقيقي باستخدام XCode7 وSwift 2.0. على الرغم من وجود العديد من البرامج التعليمية والأدلة الأساسية المتاحة، يثير التساؤل حول تجربة الفرق في مجال الiOS الذين فعلوا جاهدين لتحقيق تغطية معقولة لتطبيقاتهم الiOS/Swift المطروحة في الأسواق.
في هذا السياق، يطرح الاهتمام على النقاط التالية:
-
بينما نسبة تغطية الشيفرة لا تمثل الجودة الشاملة لقاعدة الشيفرة، هل تُستخدم هذه النسبة كمقياس أساسي في فريقك؟ وإذا لم يكن الأمر كذلك، فما هو الطريقة القابلة للقياس الأخرى لتقييم جودة قاعدة الشيفرة؟
-
بالنسبة لتطبيق أكثر قوة، ما هي نسبة تغطية الشيفرة الحالية لديكم؟ (علماً بأنه نواجه صعوبة في تجاوز الـ50% لقاعدة الشيفرة الحالية)
-
كيف تقومون باختبار أمور مثل:
- دورة حياة التطبيق، وطرق AppDelegate
- أي شيفرة تتعلق بالإشعارات الفورية أو المحلية، والربط العميق
- ممارسات البرمجة الدفاعية، والحواجز الآمنة للطمأنينة الذهنية (التي يصعب إعادة إنتاجها)، ومعالجة الاستثناءات، وغيرها
- الرسوم المتحركة، والانتقالات، وتقديم عناصر التحكم المخصصة (CG)، وغيرها
- النوافذ المنبثقة أو التنبيهات التي قد تتضمن أي منطق إضافي
يفتح هذا الاستفسار أيضًا نقاشًا حول:
-
هل هناك وسيلة معقولة لاختبار الأمور المذكورة أعلاه من منظور اختبارات الوحدات؟ وهل يجب أن نحاول حقًا تحقيق نسبة تغطية الشيفرة الحدية بواسطة اختبارات الوحدات لكامل قاعدة الشيفرة، أم يجب علينا تعريف تلك النسبة بناءً على تغطية ممكنة بشكل معقول نظرًا لشيفرة التطبيق؟
-
هل من المعقول جعل قاعدة الشيفرة أكثر صلابة من أجل تحقيق تغطية أعلى؟ (بشرط عدم التحدث عن تطبيق طبي حيث قد تكون الحياة في خطر)
-
هل هناك ممارسات جيدة لاختبار جميع الأمور المذكورة أعلاه، بخلاف اختبارات واجهة المستخدم؟
في انتظار نقاش مثمر يسلط الضوء على هذه القضايا المهمة.
المزيد من المعلومات
إضافة إلى النقاط المطروحة، يمكننا استكمال النقاش حول بعض الأفكار الرئيسية التي تتعلق بإستراتيجيات اختبار الوحدات ونسبة تغطية الشيفرة في تطبيقات iOS/Swift:
-
تقدير جودة الشيفرة بشكل شامل:
يمكن توسيع فحص جودة الشيفرة إلى أبعد من نسبة تغطية الشيفرة بحيث تشمل معايير أخرى مثل معالجة الأخطاء والاستثناءات، ومراعاة المبادئ الهندسية لبرمجة الشيفرة مثل مبدأ الفصل بين الاهتمامات والتبسيط العام للكود. -
تحديد النسبة المناسبة لتغطية الشيفرة:
قد يكون من المفيد تحديد نسبة معقولة لتغطية الشيفرة استنادًا إلى طبيعة تطبيقك ومتطلبات الأداء. يمكن أن يساعد ذلك في تحقيق توازن بين جودة الشيفرة وكفاءة التطوير. -
استراتيجيات اختبار الأمور غير القابلة للفحص بسهولة:
فيما يتعلق باختبار الأمور التي قد تكون صعبة الفحص بسبب طابعها الديناميكي، يمكن تطبيق استراتيجيات مثل تجزئة الشيفرة إلى وحدات أصغر قابلة للاختبار بشكل منفصل أو استخدام أدوات اختبار تفاعلية تقوم بمحاكاة سيناريوهات معينة. -
موازنة بين صلابة الشيفرة ومرونة التطوير:
يجب أن تكون أي جهد لجعل الشيفرة أكثر صلابة متوازنًا مع مرونة عملية التطوير. التحكم في نسبة تغطية الشيفرة يمكن أن يكون تحديًا بالنسبة لتطبيقات معقدة، ولكن ينبغي ألا يتسبب ذلك في تقليل قدرة التطبيق على التكيف مع متطلبات جديدة. -
الممارسات الجيدة لاختبار الوحدات:
يفيد استخدام ممارسات اختبار الوحدات المعتمدة على المجتمع مثل Mocking frameworks لمحاكاة أجزاء معينة من الشيفرة واختبارها بشكل معزول. هذا يمكن أن يُسهم في تسريع عملية الاختبار وتحسين تحقيق التغطية.
من خلال تسليط الضوء على هذه النقاشات وتطرح التساؤلات، يمكن أن يكون لدينا إشارات أفضل حول كيفية تحسين إستراتيجيات اختبار الوحدات وتحديد نسبة تغطية الشيفرة المثلى في تطبيقات iOS/Swift.
