اختبار الوحدة

الموسوعة الحرة

اختبار الوحدة ، المعروف أيضًا باختبار المكونات أو الوحدات ، هو شكل من أشكال اختبار البرمجيات يتم من خلاله اختبار شفرة المصدر المعزولة للتحقق من صحة السلوك المتوقع. [ 1 ]

يصف اختبار الوحدة الاختبارات التي يتم إجراؤها على مستوى الوحدة، وذلك على عكس الاختبار على مستوى التكامل أو النظام . [ 2 ]

تاريخ

يعود مبدأ اختبار الوحدات، الذي يُستخدم لاختبار أجزاء أصغر من أنظمة برمجية كبيرة بشكل منفصل، إلى بدايات هندسة البرمجيات. ففي يونيو 1956، خلال ندوة البحرية الأمريكية حول أساليب البرمجة المتقدمة للحواسيب الرقمية، قدّم إتش دي بينينجتون مشروع SAGE . اعتمد المشروع على منهجية قائمة على المواصفات، حيث تلت مرحلة البرمجة مرحلة "اختبار المعلمات" للتحقق من صحة البرامج الفرعية للمكونات وفقًا لمواصفاتها، ثم تلتها مرحلة "اختبار التجميع" للأجزاء المُجمّعة. [ 3 ] [ 4 ]

في عام 1964، وُصِفَ نهجٌ مماثلٌ لبرمجيات مشروع ميركوري ، حيث خضعت الوحدات الفردية التي طوّرها مبرمجون مختلفون لاختباراتٍ خاصةٍ قبل دمجها معًا. [ 5 ] وفي عام 1969، بدت منهجيات الاختبار أكثر تنظيمًا، حيث قامت اختبارات الوحدات واختبارات المكونات واختبارات التكامل مجتمعةً بالتحقق من صحة الأجزاء الفردية المكتوبة بشكلٍ منفصل وتجميعها التدريجي في كتلٍ أكبر. [ 6 ] وقد ساهمت بعض المعايير العامة التي اعتُمِدَت في أواخر الستينيات، مثل MIL-STD-483 [ 7 ] وMIL-STD-490، في زيادة قبول اختبار الوحدات على نطاقٍ واسعٍ في المشاريع الكبيرة.

كان اختبار الوحدات في ذلك الوقت تفاعليًا [ 4 ] أو آليًا [ 8 ] ، باستخدام اختبارات مكتوبة أو أدوات اختبار التسجيل وإعادة التشغيل. في عام 1989، وصف كينت بيك إطار عمل لاختبار لغة سمول توك (سُمي لاحقًا SUnit ) في كتابه "اختبار سمول توك البسيط: باستخدام الأنماط". في عام 1997، طوّر كينت بيك وإريك جاما وأصدرا JUnit ، وهو إطار عمل لاختبار الوحدات لاقى رواجًا بين مطوري جافا [ 9 ] . تبنّت جوجل الاختبار الآلي في الفترة ما بين 2005 و2006 [ 10 ] .

وحدة

تُعرَّف الوحدة بأنها سلوك واحد يُظهره النظام قيد الاختبار، وعادةً ما يتوافق مع أحد المتطلبات . بينما قد تتوافق الوحدة مع دالة أو وحدة نمطية واحدة (في البرمجة الإجرائية ) أو مع طريقة أو فئة واحدة (في البرمجة كائنية التوجه )، فإن الدوال/الطرق والوحدات/الفئات لا تُعتبر بالضرورة وحدات. من منظور متطلبات النظام، لا يُعتدّ إلا بمحيط النظام، وبالتالي فإن نقاط الدخول إلى سلوكيات النظام المرئية خارجيًا هي فقط التي تُحدد الوحدات. [ 11 ]

تنفيذ

يمكن إجراء اختبارات الوحدة يدويًا أو عبر تنفيذ الاختبارات الآلي . تشمل مزايا الاختبارات الآلية ما يلي: إجراء الاختبارات بشكل متكرر، وإجراء الاختبارات دون تكلفة توظيف، وإجراء اختبارات متسقة وقابلة للتكرار.

غالباً ما يقوم المبرمج الذي يكتب ويعدل الكود قيد الاختبار بإجراء الاختبارات. ويمكن اعتبار اختبار الوحدات جزءاً من عملية كتابة الكود.

معايير الاختبار

أثناء عملية التطوير، قد يقوم المبرمج بتضمين معايير أو نتائج معروفة بجودتها في الاختبار للتحقق من صحة الوحدة.

أثناء تنفيذ الاختبار، تقوم الأطر بتسجيل الاختبارات التي تفشل في أي معيار والإبلاغ عنها في ملخص.

لهذا الغرض، فإن النهج الأكثر استخدامًا هو الاختبار - الدالة - القيمة المتوقعة.

حالة اختبار

في هندسة البرمجيات ، تُعرَّف حالة الاختبار بأنها تحديد للمدخلات، وشروط التنفيذ، وإجراءات الاختبار، والنتائج المتوقعة التي تُحدد اختبارًا واحدًا يُنفَّذ لتحقيق هدف مُحدد لاختبار البرمجيات ، مثل اختبار مسار برنامج مُعين أو التحقق من الامتثال لمتطلبات مُحددة. [ 12 ] تُشكل حالات الاختبار أساسًا لاختبار منهجي بدلًا من الاختبار العشوائي. يُمكن بناء مجموعة من حالات الاختبار لتوفير التغطية المطلوبة للبرنامج قيد الاختبار. تسمح حالات الاختبار المُعرَّفة رسميًا بتشغيل الاختبارات نفسها بشكل مُتكرر على إصدارات مُتتالية من البرنامج، مما يُتيح اختبارًا فعالًا ومتسقًا للتراجع . [ 13 ]

اختبار مزدوج

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

اختبار مُعَلم

الاختبار المُعَلم هو اختبار يقبل مجموعة من القيم التي يمكن استخدامها لتشغيل الاختبار مع قيم إدخال متعددة ومختلفة. يوفر إطار الاختبار الذي يدعم الاختبارات المُعَلمة طريقة لترميز مجموعات المعلمات وتشغيل الاختبار مع كل مجموعة.

يمكن أن يقلل استخدام الاختبارات ذات المعلمات من تكرار رمز الاختبار.

يتم دعم الاختبارات ذات المعلمات بواسطة TestNG و JUnit و XUnit و NUnit ، بالإضافة إلى العديد من أطر اختبار JavaScript .

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

رؤية الكود

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

في تصميم البرمجيات الموجهة للكائنات، قد لا يتيح ذلك الوصول إلى البيانات والأساليب الخاصة. لذا، قد يتطلب الأمر جهدًا إضافيًا لاختبارات الوحدات. في جافا ولغات أخرى، يمكن للمطور استخدام الانعكاس للوصول إلى الحقول والأساليب الخاصة. [ 16 ] بدلاً من ذلك، يمكن استخدام فئة داخلية لاحتواء اختبارات الوحدات، مما يتيح لها رؤية أعضاء وخصائص الفئة المُغلِّفة. في إطار عمل .NET وبعض لغات البرمجة الأخرى، يمكن استخدام الفئات الجزئية لعرض الأساليب والبيانات الخاصة التي يمكن للاختبارات الوصول إليها.

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

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

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

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

قيمة

يهدف اختبار الوحدات إلى ضمان أن الوحدات تفي بتصميمها وتعمل كما هو مطلوب. [ 20 ]

من خلال كتابة الاختبارات أولاً لأصغر الوحدات القابلة للاختبار، ثم السلوكيات المركبة بين تلك الوحدات، يمكن للمرء بناء اختبارات شاملة للتطبيقات المعقدة. [ 20 ]

يتمثل أحد أهداف اختبار الوحدات في عزل كل جزء من البرنامج وإثبات صحة كل جزء على حدة. [ 1 ] يوفر اختبار الوحدة عقدًا مكتوبًا صارمًا يجب أن يفي به جزء الكود.

الكشف المبكر عن المشاكل في دورة التطوير

يكشف اختبار الوحدات عن المشاكل في وقت مبكر من دورة التطوير . ويشمل ذلك الأخطاء في تنفيذ المبرمج، بالإضافة إلى العيوب أو الأجزاء المفقودة من مواصفات الوحدة. وتُجبر عملية كتابة مجموعة شاملة من الاختبارات المبرمج على التفكير مليًا في المدخلات والمخرجات وحالات الخطأ، وبالتالي تحديد السلوك المطلوب للوحدة بدقة أكبر. [ 21 ]

تكلفة مخفضة

إن تكلفة اكتشاف خطأ برمجي قبل بدء كتابة الكود أو عند كتابته لأول مرة أقل بكثير من تكلفة اكتشافه وتحديده وتصحيحه لاحقًا. كما أن الأخطاء البرمجية في الكود المنشور قد تُسبب مشاكل مكلفة لمستخدمي البرنامج. [ 22 ] [ 23 ] [ 24 ] قد يكون اختبار الوحدات البرمجية صعبًا أو مستحيلاً إذا كُتب بشكل رديء، لذا فإن اختبار الوحدات يُجبر المطورين على هيكلة الدوال والكائنات بطرق أفضل.

إصدارات أكثر تواتراً

يُتيح اختبار الوحدات إصدار نسخ أكثر تكرارًا في تطوير البرمجيات. فمن خلال اختبار المكونات الفردية بشكل منفصل، يستطيع المطورون تحديد المشكلات ومعالجتها بسرعة، مما يؤدي إلى دورات تكرار وإصدار أسرع. [ 25 ]

يُتيح إعادة هيكلة الكود

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

يكشف عن التغييرات التي قد تخالف عقد التصميم

تكشف اختبارات الوحدة عن التغييرات التي قد تخالف عقد التصميم .

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

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

توثيق سلوك النظام

يرى بعض المبرمجين أن اختبارات الوحدات تُوفّر شكلاً من أشكال توثيق الكود. ويمكن للمطورين الراغبين في معرفة الوظائف التي تُقدّمها وحدةٌ ما، وكيفية استخدامها، مراجعة اختبارات الوحدات لفهمها. [ 26 ]

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

في بعض العمليات، قد يحل فعل كتابة الاختبارات والشيفرة قيد الاختبار، بالإضافة إلى إعادة هيكلتها، محل التصميم الرسمي. ويمكن اعتبار كل اختبار وحدة عنصرًا تصميميًا يحدد الفئات والأساليب والسلوك القابل للملاحظة. [ 27 ]

القيود والعيوب

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

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

يُعدّ اختبار البرمجيات مسألةً تركيبية. فعلى سبيل المثال، يتطلب كل قرار منطقي اختبارين على الأقل: أحدهما بنتيجة "صحيح" والآخر بنتيجة "خطأ". ونتيجةً لذلك، يحتاج المبرمجون غالبًا إلى كتابة ما بين 3 إلى 5 أسطر من كود الاختبار مقابل كل سطر برمجي. من الواضح أن هذا يستغرق وقتًا، وقد لا يكون الجهد المبذول مُجديًا. هناك مشاكل يصعب اختبارها على الإطلاق ، مثل تلك غير الحتمية أو التي تتضمن خيوطًا متعددة . إضافةً إلى ذلك، فإن احتمالية وجود أخطاء في كود اختبار الوحدة لا تقل عن احتمالية وجودها في الكود الذي يتم اختباره. يقول فريد بروكس في كتابه "أسطورة الشهر الرجلي" : "لا تبحر أبدًا ومعك ساعتان؛ خذ واحدة أو ثلاثًا." [ 28 ] (إذا تعارضت ساعتان ، فلا يمكن معرفة أيّهما صحيح).

صعوبة في إعداد اختبارات واقعية ومفيدة

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

يتطلب الأمر انضباطاً طوال عملية التطوير

للحصول على الفوائد المرجوة من اختبار الوحدات، يلزم اتباع انضباط صارم طوال عملية تطوير البرمجيات.

يتطلب التحكم في الإصدار

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

يتطلب مراجعات دورية

من الضروري أيضًا تطبيق عملية مستدامة لضمان مراجعة حالات فشل الاختبار بانتظام ومعالجتها فورًا. [ 30 ] إذا لم تُطبَّق هذه العملية وتُدمج في سير عمل الفريق، فسيتطور التطبيق بشكل غير متزامن مع مجموعة اختبارات الوحدة، مما يزيد من النتائج الإيجابية الخاطئة ويقلل من فعالية مجموعة الاختبارات.

قيود برمجيات الأنظمة المدمجة

يمثل اختبار وحدات برامج الأنظمة المدمجة تحديات لأن البرنامج يتم تطويره على منصة مختلفة عن تلك التي سيتم تشغيله عليها في النهاية، مما يجعل من الصعب تشغيل برنامج اختبار في بيئة النشر الفعلية، كما هو ممكن مع برامج سطح المكتب. [ 31 ]

قيود اختبار التكامل مع الأنظمة الخارجية

تكون اختبارات الوحدة أسهل عادةً عندما تحتوي الدالة على مُدخلات ومُخرجات. أما عندما يكون التفاعل مع عنصر خارجي للتطبيق هو الوظيفة الرئيسية للدالة، فلا يكون الأمر بهذه السهولة. على سبيل المثال، قد تتطلب دالة تعمل مع قاعدة بيانات إنشاء نموذج محاكاة لتفاعلات قاعدة البيانات، والذي غالبًا لن يكون شاملًا مثل تفاعلات قاعدة البيانات الحقيقية. [ 32 ]

أمثلة

وحدة مشتركة

فيما يلي مثال على مجموعة اختبارات JUnit . وهي تركز على Adderالفئة.

class Adder { public int add ( int a , int b ) { return a + b ; } }

تستخدم مجموعة الاختبارات عبارات التأكيد للتحقق من النتيجة المتوقعة لقيم الإدخال المختلفة للطريقة sum.

import static org.junit.Assert.assertEquals ; import org.junit.Test ; public class AdderUnitTest { @Test public void sumReturnsZeroForZeroInput ( ) { Adder adder = new Adder (); assertEquals ( 0 , adder.add ( 0 , 0 ) ); }@Test public void sumReturnsSumOfTwoPositiveNumbers () { Adder adder = new Adder (); assertEquals ( 3 , adder . add ( 1 , 2 )); }@Test public void sumReturnsSumOfTwoNegativeNumbers () { Adder adder = new Adder (); assertEquals ( - 3 , adder . add ( - 1 , - 2 )); }@Test public void sumReturnsSumOfLargeNumbers () { Adder adder = new Adder (); assertEquals ( 2222 , adder . add ( 1234 , 988 )); } }

كمواصفات قابلة للتنفيذ

يُعدّ استخدام اختبارات الوحدة كمواصفات تصميم ميزةً هامةً مقارنةً بأساليب التصميم الأخرى: إذ يُمكن استخدام وثيقة التصميم (اختبارات الوحدة نفسها) للتحقق من صحة التنفيذ. ولن تجتاز الاختبارات بنجاح إلا إذا قام المطور بتنفيذ حلٍّ وفقًا للتصميم.

يفتقر اختبار الوحدات إلى بعض سهولة الوصول التي توفرها المواصفات التخطيطية، مثل مخطط UML ، ولكن يمكن توليدها من اختبار الوحدة باستخدام أدوات مؤتمتة. تتوفر أدوات مجانية لمعظم لغات البرمجة الحديثة (عادةً كإضافات لبيئات التطوير المتكاملة ). تُسند الأدوات المجانية، مثل تلك المبنية على إطار عمل xUnit ، مهمة العرض الرسومي للواجهة إلى نظام آخر. [ 33 ]

التطبيقات

البرمجة المتطرفة

يُعد اختبار الوحدات حجر الزاوية في البرمجة المتطرفة ، التي تعتمد على إطار عمل آلي لاختبار الوحدات . يمكن أن يكون إطار العمل هذا تابعًا لجهة خارجية، مثل xUnit ، أو يتم إنشاؤه داخل فريق التطوير.

تعتمد البرمجة المتطرفة على إنشاء اختبارات الوحدة لتطوير البرمجيات الموجه بالاختبار . يكتب المطور اختبار وحدة يكشف إما عن متطلب برمجي أو عن عيب فيه. سيفشل هذا الاختبار إما لأن المتطلب لم يُنفذ بعد، أو لأنه يكشف عمدًا عن عيب في الكود الحالي. بعد ذلك، يكتب المطور أبسط كود ممكن لجعل الاختبار، إلى جانب الاختبارات الأخرى، ينجح.

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

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

يُعد اختبار الوحدات أمرًا بالغ الأهمية لمفهوم التصميم الناشئ ، الذي يطور تصميم البرمجيات بشكل تكراري من خلال دورات تطوير قصيرة تعتمد على الاختبار ، تتضمن كتابة اختبار وحدة، والتأكد من نجاحه، وإعادة هيكلة الكود؛ وتوفر اختبارات الوحدات شبكة أمان ضد التراجع تجعل إعادة الهيكلة المستمرة آمنة. [ 35 ]

أطر الاختبار الآلي

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

بشكل عام، تكون الأطر البرمجية تابعة لجهات خارجية ، ولا يتم توزيعها مع مترجم أو بيئة تطوير متكاملة (IDE).

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

في بعض الأطر، تكون ميزات الاختبار المتقدمة مفقودة ويجب برمجتها يدويًا.

دعم اختبار الوحدات على مستوى اللغة

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

تشمل اللغات التي تدعم اختبار الوحدات المدمج ما يلي:

تشمل اللغات التي تدعم إطار عمل اختبار الوحدات القياسي ما يلي:

بعض لغات البرمجة لا تدعم اختبارات الوحدات المدمجة، ولكنها تمتلك مكتبات أو أطر عمل مخصصة لاختبار الوحدات. وتشمل هذه اللغات ما يلي:

انظر أيضاً

مراجع

  1. 1 2 كولاوا، آدم؛ هويزينغا، دوروتا (2007). الوقاية الآلية من العيوب: أفضل الممارسات في إدارة البرمجيات . مطبعة وايلي-IEEE لجمعية الحاسبات. ص  75. ISBN 978-0-470-04212-0.
  2. ↑ خدمات أمازون السحابية (AWS). (بدون تاريخ). ما هو اختبار الوحدات؟ تم الاسترجاع في 2 مايو 2025 من( https://aws.amazon.com/what-is/unit-testing/ )
  3. ↑ بينينجتون، هربرت د. (1956). "إنتاج برامج حاسوبية ضخمة". وقائع ندوة أساليب البرمجة المتقدمة للحواسيب الرقمية، واشنطن العاصمة، 28-29 يونيو 1956. مكتب البحوث البحرية، وزارة البحرية: 15-28 .
  4. بينينغتون ، إتش دي (1 مارس 1987). "إنتاج برامج حاسوبية ضخمة (إعادة طبع ورقة بحثية من عام 1956 مع مقدمة محدثة)" . وقائع المؤتمر الدولي التاسع لهندسة البرمجيات . ICSE '87. واشنطن العاصمة، الولايات المتحدة الأمريكية: مطبعة جمعية مهندسي الكهرباء والإلكترونيات: 299-310 . ISBN 978-0-89791-216-7.
  5. ↑ دونيغان، جيمس جيه؛ باكارد، كالفن؛ باشبي، بول (1 يناير 1964). "تجارب مع نظام غودارد للحوسبة خلال مهمات رحلات الفضاء المأهولة" . وقائع المؤتمر الوطني التاسع عشر لجمعية آلات الحوسبة لعام 1964. ACM '64. نيويورك، نيويورك، الولايات المتحدة الأمريكية: جمعية آلات الحوسبة. الصفحات 12.101-12.108 . doi : 10.1145/800257.808889 . ISBN  978-1-4503-7918-2.{{cite book}}عدم توافق رقم ISBN / التاريخ ( مساعدة )
  6. ↑ زيمرمان، نورمان أ. (26 أغسطس 1969). "تكامل الأنظمة كوظيفة برمجية" . وقائع المؤتمر الوطني الرابع والعشرين لعام 1969. ACM '69. نيويورك، نيويورك، الولايات المتحدة الأمريكية: رابطة آلات الحوسبة. الصفحات 459-467 . doi : 10.1145/800195.805951 . ISBN  978-1-4503-7493-4.
  7. ↑ المعيار العسكري MIL-STD-483: ممارسات إدارة التكوين للأنظمة والمعدات والذخائر وبرامج الحاسوب . الولايات المتحدة، وزارة الدفاع. 31 ديسمبر 1970. ص. القسم 3.4.7.2. يجب على المقاول بعد ذلك برمجة واختبار وحدات البرمجيات، وإدخال شفرة المصدر وشفرة الكائن، والقوائم المرتبطة بكل وحدة تم اختبارها بنجاح في تكوين التطوير. 
  8. ↑ تايغ، مايكل ف. (1 يناير 1978). "قيمة منهجية ضمان جودة البرمجيات المناسبة" . مجلة ACM SIGMETRICS لتقييم الأداء . 7 ( 3-4 ): 165-172 . doi : 10.1145/1007775.811118 . ISSN 0163-5999 . 
  9. ↑ جولاتي، شيخار (2017). اختبار وحدات جافا باستخدام JUnit 5 : تطوير قائم على الاختبار باستخدام JUnit 5. راهول شارما. بيركلي، كاليفورنيا: Apress. ص 8. ISBN   978-1-4842-3015-2. OCLC 1012347252 . 
  10. ↑ وينترز، تيتوس (2020). هندسة البرمجيات في جوجل : دروس مستفادة من البرمجة عبر الزمن . توم مانشريك، هايروم رايت ( الطبعة الأولى). سيباستوبول، كاليفورنيا: أورايلي. ISBN   978-1-4920-8274-3. OCLC 1144086840 . 
  11. ↑ بيك، كينت (2002). تطوير البرمجيات الموجه بالاختبارات من خلال الأمثلة . أديسون-ويسلي. ISBN 978-0321146533.
  12. ↑ هندسة النظم والبرمجيات - المصطلحات . ISO/IEC/IEEE 24765:2010(E). 1 ديسمبر 2010. الصفحات 1-418. doi : 10.1109 / IEEESTD.2010.5733835 . ISBN  978-0-7381-6205-8.
  13. ↑ كانر، سيم (مايو 2003). "ما هي حالة الاختبار الجيدة؟" (ملف PDF) . ستار إيست : 2.
  14. ↑ Gulati & Sharma 2017 ، ص 133-137 ، الفصل §7 JUnit 5 نموذج الامتداد - الاختبار المعلم.
  15. ↑ كامبمان، ألكسندر؛ زيلر، أندرياس (مايو 2019). "نحت اختبارات الوحدة المُعَلمة". المؤتمر الدولي الحادي والأربعون لهندسة البرمجيات IEEE/ACM لعام 2019: وقائع المؤتمر المصاحب (ICSE-Companion) . الصفحات 248-249 . doi : 10.1109/icse-companion.2019.00098 . ISBN  978-1-7281-1764-5.
  16. ↑ بيرتون، روس (12 نوفمبر 2003). "التحايل على حماية الوصول في جافا لاختبار الوحدات" . أورايلي ميديا، إنك . تم الاطلاع عليه في 12 أغسطس 2009 .
  17. ↑ فان روسوم، غيدو؛ وارسو، باري (5 يوليو 2001). "PEP 8 - دليل أسلوب كتابة كود بايثون" . مؤسسة برمجيات بايثون . تم الاطلاع عليه في 6 مايو 2012 .
  18. ↑ نيوركيرك، جيمس (7 يونيو 2004). "اختبار الطرق الخاصة/المتغيرات الأعضاء - هل ينبغي عليك فعل ذلك أم لا؟" . شركة مايكروسوفت . تم الاطلاع عليه بتاريخ 12 أغسطس 2009 .
  19. ↑ ستال، تيم (1 مارس 2005). "كيفية اختبار الطرق الخاصة والمحمية في .NET" . CodeProject. مؤرشف من الأصل في 3 سبتمبر 2009. تم الاطلاع عليه في 12 أغسطس 2009 .
  20. 1 2 هاميل، بول (2004). أُطر اختبار الوحدات: أدوات لتطوير برمجيات عالية الجودة . دار نشر أورايلي ميديا. رقم ISBN 9780596552817.
  21. ↑ غرين، لوكاس؛ أنتينيان، فارد (أغسطس 2017). حول العلاقة بين اختبار الوحدات وجودة الكود . المؤتمر الثالث والأربعون لـ Euromicro حول هندسة البرمجيات والتطبيقات المتقدمة (SEAA). الصفحات 52-56 . doi : 10.1109/seaa.2017.36 . تاريخ الاسترجاع: 16 مايو 2026 . 
  22. ↑ بوهم، باري دبليو ؛ باباتشيو، فيليب ن. (أكتوبر 1988). "فهم تكاليف البرمجيات والتحكم بها" (ملف PDF) . مجلة IEEE للمعاملات في هندسة البرمجيات . 14 (10): 1462-1477 . رمز Bibcode : 1988ITSEn..14.1462B . doi : 10.1109/32.6191 . مؤرشف من الأصل (ملف PDF) في 9 أكتوبر 2016. تم الاطلاع عليه في 13 مايو 2016 .
  23. ↑ "اختبر مبكراً وبشكل متكرر" . مايكروسوفت.
  24. ↑ "إثبات فعاليته: استخدام إطار اختبار الوحدة لاختبار البرمجيات والتحقق من صحتها" . شركة ناشيونال إنسترومنتس . 21 أغسطس 2017.
  25. ↑ إريك (10 مارس 2023). "ما زلت لا تعرف كيفية إجراء اختبارات الوحدة (وسرّك في أمان معي)" . ستاكيفاي . تم الاطلاع عليه في 10 مارس 2023 .
  26. ↑ ستوكر، كارستن؛ واشيزاكي، هيرونوري؛ فوكازاوا، يوشياكي (مارس 2017). "سد الفجوة بين كود اختبار الوحدة والتوثيق". ورش عمل المؤتمر الدولي IEEE لاختبار البرمجيات والتحقق منها والتحقق من صحتها (ICSTW) لعام 2017. الصفحات 304-308 . doi : 10.1109/icstw.2017.56 . ISBN  978-1-5090-6676-6.
  27. ↑ نصيف، م.؛ هيرنانديز، أليكسا؛ سريدهاران، أشفيثا؛ روبيلارد، م. (2022). "إنشاء اختبارات الوحدة للتوثيق". معاملات IEEE في هندسة البرمجيات . 48 (9): 3268-3279 . arXiv : 2005.08750 . Bibcode : 2022ITSEn..48.3268N . doi : 10.1109/TSE.2021.3087087 .
  28. ↑ بروكس، فريدريك ج. ( 1995) [1975]. الشهر الأسطوري للرجل . أديسون-ويسلي. ص 64. ISBN  978-0-201-83595-3.
  29. ↑ تيواري، ديبكا؛ مونبيروس، مارتن؛ بودري، بينوا (نوفمبر 2024). "محاكاة سلوك الإنتاج باستخدام نماذج محاكاة مُولَّدة". معاملات IEEE في هندسة البرمجيات . 50 (11): 2921-2946 . Bibcode : 2024ITSEn..50.2921T . doi : 10.1109/tse.2024.3458448 . ISSN 2326-3881 . 
  30. ↑ دافيغا، ندى (6 فبراير 2008). "تغيير الكود دون خوف: استخدام شبكة أمان للتراجع" . تم الاسترجاع في 8 فبراير 2008 .
  31. ↑ كوتشارسكي، ماريك (23 نوفمبر 2011). "جعل اختبار الوحدات عمليًا لتطوير الأنظمة المدمجة" . تم الاطلاع عليه في 20 يوليو 2020 .
  32. ↑ "اختبارات الوحدة وقواعد البيانات" . تم الاطلاع عليه بتاريخ 29 يناير 2024 .
  33. ↑ جيكس فور جيكس. (2024). اختبار الوحدات . تم الاسترجاع في 2 مايو 2025 من( https://www.geeksforgeeks.org/unit-testing-software-testing/ )
  34. ↑ بيك، كينت (أكتوبر 1999). "شرح البرمجة المتطرفة: تقبّل التغيير" . مجلة الكمبيوتر . 32 (10): 70-76 . doi : 10.1109/52.844236 (غير نشط في 15 مايو 2026) . تم الاطلاع عليه في 7 مايو 2026 .{{cite journal}}: صيانة CS1: رقم التعريف الرقمي غير نشط اعتبارًا من مايو 2026 ( رابط )
  35. ↑ فوتشي، دافيد؛ إردوغموس، هاكان؛ تورهان، بوراك؛ أويفو، ماركو؛ يوريستو، ناتاليا (2017). "تحليل عملية التطوير القائمة على الاختبار: هل يهم حقًا الاختبار أولًا أم أخيرًا؟" . مجلة IEEE للمعاملات في هندسة البرمجيات . 43 (7): 597-614 . doi : 10.1109/tse.2016.2616877 . ISSN 1939-3520 . تاريخ الاسترجاع: 25 مايو 2026 . 
  36. ↑ شركة بولز آي لتكنولوجيا الاختبارات (2006-2008). "أهداف التغطية المتوسطة" . تم الاطلاع عليه بتاريخ 24 مارس 2009 .
  37. ↑ "اختبارات الوحدة - لغة البرمجة D" . لغة البرمجة D. مؤسسة لغة D. تم الاطلاع عليه بتاريخ 5 أغسطس 2017 .
  38. ↑ ستيف كلابنيك وكارول نيكولز، بمساهمات من مجتمع Rust (2015-2023). "كيفية كتابة الاختبارات" . تم الاطلاع عليه بتاريخ 21 أغسطس 2023 .
  39. ↑ "مواصفات الكريستال" . crystal-lang.org . تم الاطلاع عليه بتاريخ 18 سبتمبر 2017 .
  40. ↑ "الاختبار - لغة البرمجة Go" . golang.org . تم الاطلاع عليه في 3 ديسمبر 2013 .
  41. ↑ "اختبار الوحدات · لغة جوليا" . docs.julialang.org . تم الاطلاع عليه بتاريخ 15 يونيو 2022 .
  42. ↑ وثائق بايثون (2016). "unittest -- إطار عمل لاختبار الوحدات" . تم الاطلاع عليه بتاريخ 18 أبريل 2016 .
  43. ↑ ويلش، نويل؛ كولبيبر، رايان. "RackUnit: اختبار الوحدات" . شركة PLT Design Inc. تم الاسترجاع في 26 فبراير 2019 .
  44. ↑ ويلش، نويل؛ كولبيبر، رايان. "حزمة اختبار وحدة RackUnit جزء من التوزيعة الرئيسية لـ Racket" . شركة PLT Design Inc. تم الاسترجاع في 26 فبراير 2019 .
  45. ^ "مينيتيست (روبي 2.0)" . روبي-Doc.org.
  46. ↑ سييرا، ستيوارت. "واجهة برمجة التطبيقات لـ clojure.test - Clojure v1.6 (مستقر)" . تم الاطلاع عليه بتاريخ 11 فبراير 2015 .
  47. ↑ "إطار عمل بيستر" . جيت هاب . تم الاطلاع عليه بتاريخ 28 يناير 2016 .

للمزيد من القراءة

  • فيذرز، مايكل سي. (2005). العمل بفعالية مع البرامج القديمة . أبر سادل ريفر، نيوجيرسي: برنتيس هول بروفيشنال تكنيكال ريفرنس. ISBN 978-0131177055.
  • جولاتي، شيخار؛ شارما، راهول (2017). اختبار الوحدات في جافا باستخدام JUnit 5. Apress .