13

التطوير المقاد بالإختبار أو وحدات الاختبار Unit Test، هي إحدى العمليات أو الممارسات البرمجية التي تستخدم أثناء تطوير البرنامج والتي تهدف ضمان أن جميع الأكواد تظل دائما تعطي نفس النتائج المطلوبة والمتوقعة على مرّ مراحل تتطوير البرنامج.

كيف تتّم هذه الممارسة؟

ببساطة، قبل أن تكتب كود ال function (وظيفة، إجرائية، نهجية) تقوم بكتابة إجرائية اختبار لها.

مثال: نريد كتابة دالة GetAge والتي سوف تعطينا ما بلغه عمر الفرد بالسنوات بعد أن نمرّر لها السنة الحالية وسنة ميلاد الفرد. قبل كتابة هذه الدالة؛ نقوم بكتابة دالة اختبار لها، كالتالي: (صيغة الكود هنا للتوضيح وليس لها علاقة بلغة برمجية محددة)

function test_GetAge
{
    Age = getAge(2014, 1980)
    if Age = 34 return true
    else  return false
}

لاحظ اننا في دالة الاختبار أعطينا لدالة getAge بيانات السنة الحالية وسنة الميلاد، ونتوقع أن تردّ لنا القيمة 34. ثم نكتب كود الدالة GetAge

function getAge(Year, BirthYear)
{
    x = Year - BirthYear 
    return x
}

نستدعي دالة الاختبار test_GetAge فإذا أعطتنا نتيجة موجبة فذلك يعني يعني أن دالة getAge تعمل يصورة سليمة.

وهكذا مع كل إجرائية أو وظيفة جديدة في برنامجك تقوم مقابلها بإنشاء إجرائية اختبار لها.

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

مع تنامي الإجرائيات الجديدة وتطوّر البرنامج و تضخّمه؛ قد تقوم لاحقا ببعض التغييرات في إحدى الإجرائيات والدوال من أجل تحسينها وزيادة ضبطها أو من أجل جعلها تتوافق مع إجرائيات جديدة أدخلتها للبرنامج أو حتى إعادة تنسيق أسطرها. هذه التغييرات قد تؤدي إلى تغيير سلوك بعض الإجرائيات الأخرى دون قصد منك أو انتباه. ونتيجة لكبر البرنامج سيكون من الصعب ملاحظة هذا التغيير والذي سيكون علّة أو ثغرة في البرنامج.

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

  • لاحظ، في هذه النمط من عمليات التطوير يتم كتابة كود اختبار الاجرائية قبل كتابة الاجرائية نفسها.(بل يجب استدعاء الاختبار أولا والذي بدوره سوف يستدعي الاجرائية التي هي غير موجودة بعد !! فينتج طبعا خطأ، وهو دليل على صحة كود الاختبار). لذلك سمي هذا النمط من الممارسة البرمجية: التطوير المُقاد بالإختبار.

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

لذلك، في كثير من الأحيان يكون من الصعب كتابة اختبار لاحق لإجرائية مكتوبة سابقا، وأن الأمر يتطلّب إعادة هيكلة الإجرائية أو تقسيمها لإجرائيات أصغر، حتى تكون ملائمة لإستدعائها وتجربتها من قبل كود الاختبار.

  • المبرمج الذي يريد تبنّي هذه الممارسة، قد يجد صعوبة في البداية، فعملية كتابة إجرائية اختبار مع كلّ إجرائية في البرنامج سيكون عملا مرهقا وزيادة في كمية العمل، كذلك التفكير في إجرائية الاختبار وكتابتها قبل كتابة الكود الفعلي أمر مربك ومشتّت للذهن. ولكن مع الصبر والعزم، سيجد المبرمج نفسه متعوّدا على ذلك، وربما تصبح ممارسة أساسية لديه لايستطيع الاستغناء عنها.

  • طبعا، وكأي ممارسة برمجية، يجب عدم التطرّف فيها، بحيث يمكن للمبرمج أو فريق العمل اختيار أجزاء من البرنامج دون أخرى لإخضاعها لعمليات الاختبار.

  • منذ ظهور هذه الممارسة، وتسمى Test unit ظهر الكثير من أطر العمل التي تسهّل على المبرمج بناء إجرائيات الاختبار، وتأتي عادة تحت تسمية xUnit مع استبدال حرف x باللغة أو البيئة المستهدفة، مثل CUnit ، JUnit ، NUnit وهكذا.

  • كأي ممارسة برمجية، فإن البرمجة المقادة بالاختبار لها فوائدها و لها عيوبها، أيضا لديها المناصرين لها والمشككين فيها. المشكّكون يرون أن جهذا كبيرا يتم بذله نتيجة كتابة أكواد جانبية لا تخدم المتطلبات الوظيفية الأصلية للبرنامج، و بالتالي فإن وقتا ثمينا يتم اهداره، وأن هذا الوقت يكون أولى لو أنه خصّص للبرنامج. وأنه يمكن الحصول على الفوائد نفسها من خلال تحسين العادات البرمجية للمبرمج، ومن خلال اعتماد مذاهب برمجية مثل البرمجة الوظائفية Functional Programming للحدّ من التأثيرات الجانبية للإجرائيات في بعضها.

إلا أن المدافعين عنها يرون أن الثقة التي يتحصّل عليها المطوّرون في برامجهم نتيجة لوحدات الاختبار أمر لا يقّر بثمن، كما أن الذين يتخلّون عن الاختبارت الممنهجة سوف سوف يدفعون ثمنا مضاعفا عندما تظهر العلل والثغرات في برامجهم ويمضون الساعات الطوال في تعقّب واكتشاف هذه العلل وإصلاحها.

والله أعلم.

تفضل هذا كورس بالعربي في موقع رواق عن البرمجة المقادة بالإختبارات

http://www.rwaq.org/courses/test-driven-development

http://en.wikipedia.org/wiki/Test-driven_development

اطلعت عليه، لكن أردت أن يجيبني أحد المحترفين ويعطيني نظرة شاملة قبل أن أتطرق للتفاصيل فيما بعد.

شكرا لك على العموم :-)

هناك خمسه فصول لتطوير التطبيقات في هندسة البرمجيات

التحليل

التصميم << ليس تصميم الواجهة بل النمط الداخلي مثل قاعدة البيانات

التكويد

الاختبار

التطوير على المدى البعيد

كل فصل يمتلك خطط واستراتجيات وطريقة تعامل

الاختبار يمتلك ايضا استراتجيات مثل

هل اقوم باختبار كل وحدة على حدى ام ادمجهم كلهم واختبرهم ؟

هل استعين بتطبيق خارجي لاختبار وحداتي ،هناك تطبيقات تقوم لك بعدد من الاختبارات مثل اختبار الاوفس وصل الى ١٣ الف اختبار

اختبار الوحدات بطريقة الملاحظة

اختبار الوحدات بطريقة الاختبار العجيب بمعنى لنفترض حقل يطلب اسم المستخدم ووضعت ٠ مالذي سيحدث ! هذا ماحدث مع تويوتا عندما ظنوا انه لن يكون هناك انسان يضغط البانزين والفرامل معاً وتفاجئوا بعدد القضايا المرفوعة عليهم بسبب اهمالهم هذا الاختبار

الاختبار فصل كامل في هندسة البرمجيات ويندرج تحته الفالديشين والفيرفكيشن واطلاق نسخ الالفا والبيتا ليساعد المستخدم في اكتشاف العيوب وارسالها وهو لايقل اهمية عن البرمجة وهو مايميزك كمبرمج محترف وللاسف هو مهمل عند العرب لكن كبار الشركات الاجنبية تطبقه

المصدر في كتابة هندسة البرمجيات الاصدار التاسع

http://www.softwareengineering-9.com

سؤال جميل

برمجة

المواضيع والنقاشات المتعلقة بالبرمجة بشكل عام او لغات البرمجة التي لايوجد لها مجتمعات فرعية.

16.4 ألف متابع