التطوير المقاد بالإختبار أو وحدات الاختبار 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 للحدّ من التأثيرات الجانبية للإجرائيات في بعضها.
إلا أن المدافعين عنها يرون أن الثقة التي يتحصّل عليها المطوّرون في برامجهم نتيجة لوحدات الاختبار أمر لا يقّر بثمن، كما أن الذين يتخلّون عن الاختبارت الممنهجة سوف سوف يدفعون ثمنا مضاعفا عندما تظهر العلل والثغرات في برامجهم ويمضون الساعات الطوال في تعقّب واكتشاف هذه العلل وإصلاحها.
والله أعلم.
التعليقات