هل تكتب Unit Tests؟ وبأي أداة؟ وكم درجة Coverage؟

Unit Tests

لا اعرف معناها هل يمكنك ولو شرح بسيط عنها

هل هي اختبارات الصندوق الابيض والاسود ؟؟؟؟؟؟؟؟؟؟؟؟

بالتوفيق والانتظار

كلا، نادرا ما اتعب نفسي بكتابتها، اكتبها فقط اذا كان هناك جزء حساس في لب البرنامج

X-File كتب:

Unit Tests

لا اعرف معناها هل يمكنك ولو شرح بسيط عنها

هل هي اختبارات الصندوق الابيض والاسود ؟؟؟؟؟؟؟؟؟؟؟؟

بالتوفيق والانتظار

الـ Unit Test هي اختبار وحدة معينة في البرنامج عادة ما يكون Class واحد منعزلاً تماماً عن أي قطعة أخرى بالبرنامج .. فهو مسئول عن اختبار وحدة وحدة بالبرنامج ككل.

hasan_aljudy كتب:

كلا، نادرا ما اتعب نفسي بكتابتها، اكتبها فقط اذا كان هناك جزء حساس في لب البرنامج

يظن البعض أن الـ Unit Tests تعب ولكن هذا لا يصح أبداً فهي بمثابة شبكة الأمان للبرنامج. فلذلك أنا أستغرب جداً من قولك (نادراً)! فكيف لبرنامج احترافي أن يعمل بكفاءة دون وجود Unit Tests تثبت على أرض الواقع أن الكود يعمل بكفاءة قبل أن يستخدمه المستخدم أو حتى المبرمج الذي سيقوم بتسلم المشروع أو الكود منك ليكمل عليه. أيضاً كيف لبرنامج احترافي لا يحتوي على Unit Tests لسهولة كشف الـ Bugs وإصلاحها. فشتان الفارق بين برنامج لا يحتوي على Unit Tests وأخر يحتوي عليه.

ولكن حتى وإن كنت تكتبه نادراً .. ما هي الأدوات التي تستخدمها من أجل الـ unit testing نفسه .. والـ mocking framework؟ وأي طريقة تستخدم .. TDD أم تختبر ما كتبته بعد كتابته؟

جزاكم الله خيراً

الـ unit test لا يثبت شيء بالضرورة .. كل ما يثبته هو ان جزء معين من الكود يفعل ما هو مصمم لفعله. و لكن هل هذا يعني ان البرنامج ذو كفائة؟ لا ادري .. ربما الكود اصلا تعبان و الـ unit test مجرد "اسقاط فرض" او عذر لكتابة كود تعبان.

بالنسبة لي الاجزاء الحساسة هي الاجزاء المركزية اللتي تعتمد عليها بقية اجزاء البرنامج، و هذه هي الاجزاء اللتي تحتاج الى اختبارات اكثر من غيرها.

ايضا المواضع اللتي فيها بعض الحسابات المعقدة، يعني يمكن اليوم اكون فاهمها لكن الاسبوع القادم لو نظرت اليها لن افهم شيء .. و هنا الهدف من الـ unit test هو اعطائي بعض الثقة في ان اقوم بتغيير بعض الاشياء مع التأكد من ان الحسابات المعقدة تلك لا زالت تعمل بشكل صحيح.

اما فيما عدا ذلك ... فلست مقتنعا ان كل جزئية في البرنامج تستحق كتابة unit test خاص بها ..

أحمد عبد المنعم كتب:

ولكن حتى وإن كنت تكتبه نادراً .. ما هي الأدوات التي تستخدمها من أجل الـ unit testing نفسه .. والـ mocking framework؟ وأي طريقة تستخدم .. TDD أم تختبر ما كتبته بعد كتابته؟

جزاكم الله خيراً

أما أنا, فصوت ب "لا"

لأني نادرا ما أكتب Unit Testing حتي لو فعلت ذلك فأفعل ذلك غالبا بدون أي أداة لل unit testing

نادرا ما أستخدم Unit testing , لأني نادرا ما أكتب دالة أو فئة كاملة من الصفر :D

أفعل أحيانا عندما أكتب دالة جديده (بل عندما أكتب دالة أو فئة جديده لابد من أن أقوم بعمل Unit testing لها ) , و إذا كانت من ضمن مشروع يستخدمون فيه JUnit فإني أستخدمه أنا الأخر و إلا فإن أستخدم simple main methond :D وغالبا ما أقوم بمسحها قبيل ال check-in .

لم أستخدم ال Mocking إطلاقا إلا أنني أعرف ما الفائده منه.

لم يسبق لى العمل مع TDD مطلقا من قبل.

و دائما ما أقوم بعمل functional testing بعد الإنتهاء من المشكله التي أقوم بحلها, لأن هذه هي متطلبات النظام الذي أعمل بداخله (freak process :D)

داخل العمل MSTEST و نسبة الCoverage على الأقل 70%

في المنزل Nunit

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

بالنسبة لي فأنا أعمل بـ MSTEST سواء في العمل أو المنزل

أستخدم Rhino Mocks كـ Mocking framework

ونسبة الـ Coverage ففي الأكواد الموجودة في الـ Tiers أو Layers الخلفية النسبة يجب أن تكون بين 80 - 100% ... وأنا عموماً دائماً أحاول أن تكون النسبة كذلك لإيماني الشديد بأهمية الـ Unit Test

في الحقيقة أنا كتبت هذا الموضوع حتى أتحقق من أمر ما ..

وهو أن معظم الشركات العربية - إلا من رحم ربي فيما ندر - يهتم بهذا الأمر أصلاً. ولهذا تجد معظم المبرمجين العرب في بلاد العرب يقل وبشدة فهمهم للـ Unit Tests أو حتى لأهميته إلا من رحم ربي.

هناك أكثر من نقطة وردت في الردود ..

مثلاً: عدم استخدام Framework للـ Unit test والاكتفاء بكتابة الـ Test مثلاً باستخدام Console application هذه الطريقة لها عيوب كثيرة جداً من أهمها أنك لن تستطيع تشغيل هذا الـ Test بعد ذلك لأنك ستحذفه! ومنها أنك في العادة تقوم باختبار دالة بأكثر من دالة في الـ Unit Test ولكن في الـ Console أنت لديك Main واحدة فقط كيف ستفعل ذلك؟! هل ستقوم بعمل دوال فرعية يقوم الـ Main باستدعائها .. أولاً لن تحقق الغرض! ثانياً ستضيع وقتك في التفكير كيفية تقسيم الـ Main. وهناك أمور كثيرة جداً أخرى ولكن لن يتسع الكلام لها الآن.

أيضاً الـ Mocking frameworks من أساسيات الـ Unit Tests وإلا إذا كنت تقوم باختبار دالة معينة تتعامل مع وحدة أخرى في البرنامج ولم تقم بعمل Mock أو لم تستخدم أي Mocking framework إذن فهذا Integration Test وليس Unit Test.

الاهتمام أيضاً بالـ Unit Tests سيجعلك عادة تكتب كود مختلف تماماً عن أكوادك السابقة تحاول فيه دائماً وبكل طريق أن تجعله decoupled ستعتمد فيه جل الوقت على الـ Interfaces وسيجعلك تفكر أيضاً في الـ UI Patterns مثل الـ MVC و الـ MVP أو MVVM .... وغير ذلك حتى تستطيع اختبار الكود الموجود داخل صفحات الويب أو داخل الـ UI Form عموماً.

إذا فكرت في أن الـ Unit Tests ستكون بمثابة شبكة النجاة أو كما يقولون safety net لك حين تسقط في غياهب الـ refactoring وال bug tracking and identification .. فصدقني ستستغرب حياتك قبله تماماً كذلك كنت أنا أيضاً.

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

اعتمد فى عملى على ال TDD و استخدم ال NUnit لل Tests و ال Mocking فى نفس الوقت (لم يتسن لى وقت للعمل مع Rhino مع علمى بانها افضل ك Mocking Framework)

من أفضل المقتطفات التي قرأتها:

طارق إبراهيم كتب:

(لم يتسن لى وقت للعمل مع Rhino مع علمى بانها افضل ك Mocking Framework)

هو رائع وبسيط ..

ولكن له عيوب أيضاً على ما أتذكر لا يمكنه عمل Mock من Static Class مثلاً.

هناك Frameworks أخرى قوية ولكن ليست مجانية .. مثل TypeMock

اقتباس

ولطالما حلمت أن يتغير مبرمجينا للأفضل دائماً واتباع المعايير العالمية المفيدة في مجال البرمجة بصفة عامة.

انا شخصيا احلم ان يتغير مبرمجينا نحو الافضل عن طريق تشغيل عقولهم .. و ليس اتباع ما قرأوه في كتاب هنا او هناك.

بعض "المعايير" وضعت من اجل المدراء و ليس من اجل المبرمجين

لكن هذا موضوع آخر .. راجع revenge of the nerds *

ما اريد قوله، انا لست مقتنع باهمية عمل Unit test لكل شيء، كما قلت انا اكتفي بالمواضع الحساسة من البرنامج او الاشياء المركزية اللتي تعتمد عليها الكثير من الاجزاء الاخرى من البرنامج، اضافة الى المواضع اللتي فيها بعض التعقيد.

اما حكاية انه معيار عالمي فهذه ما تعبر عندي بنوب (ما بتعديش عندي خالص)، و بعبارة اخرى فحكاية معيار و ما معيار ليست سببا مقنعا لاتباع الاسلوب الفلاني او العلاني في البرمجة.

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

و لهذا احاول الحد من كمية الاختبارات اللتي اكتبها، و كما يقولون keep it to a minimum

بالنسبة للـ framework فحسب اللغة، بايثون فيها فريمورك اسمه unittest

و في العمل نستخدم NUnit (سي شارب).

------------------------------------

* بخصوص حكاية المعايير، فما احب اقتباسه من ذلك المقال هو الفقرة التالية:

This is the kind of possibility that the pointy-haired boss doesn't even want to think about. And so most of them don't. Because, you know, when it comes down to it, the pointy-haired boss doesn't mind if his company gets their ass kicked, so long as no one can prove it's his fault. The safest plan for him personally is to stick close to the center of the herd.

Within large organizations, the phrase used to describe this approach is "industry best practice." Its purpose is to shield the pointy-haired boss from responsibility: if he chooses something that is "industry best practice," and the company loses, he can't be blamed. He didn't choose, the industry did.

اقتباس

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

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

هناك فرق اخى حسان بين ال Unit Test من جانبنا كمطورين و بين الاختبارات التى يقوم بها فريق العمل من ال Test Engineers

اقتباس

انا شخصيا احلم ان يتغير مبرمجينا نحو الافضل عن طريق تشغيل عقولهم .. و ليس اتباع ما قرأوه في كتاب هنا او هناك.

كنت اعتقد مثلك منذ سوات لحين تعلمت ان هؤلاء لم يقوموا بكتابة ما كتبوا و هم يشاهون التلفاز و بجانبهم طبق الفشار

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

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

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

النقطة الثانية قولي أنه معيار عالمي لم أقصد Standard وضع بطريقة أ ب ت .. ولكنه أثبت بما لا يدع مجالاً للشك أنه أقوى طريقة للحفاظ على قوام البرنامج من العبث وأثبت أيضاً بما لا يدع مجالاً للشك أنه أفضل طريقة لاكتشاف الـ Bugs وتتبعها وحلها. فهذه حقائق علمية ولا تحتمل التأويل.

وبخصوص أن الـ Unit Tests غير مهيكلة وكثيرة الأخطاء وستكون عبئاً على المشروع .. فنعم أنا أتفق معك في حالة أن يكون كاتب هذه الاختبارات مبتديء في مجال الـ Unit Testing ومع الوقت (كأي شيء في العالم) سيعرف كيف ينظمه بطريقة جيدة ويجعله Maintainable.

طبعاً أنا أتفقهم وجهة نظرك ولا ألومك عليها ..فهذه الأعذار قديمة ومكتوبة بالنص ومفندة في كتاب Pragmatic Unit Testing يمكنك أن تقرأها في هذا البند 1.6 Excuses For Not Testing. أيضاً يمكنك الرجوع إلى كتاب Art of unit testing ففيه الكثير والكثير.

بخصوص مبدأ keep it to minimum .. أو مبدأ KISS = Keep it stupid, simple فالمقصود به الكود الذي سوف يتم تشغيله لينتج البرنامج الذي يجلس عليه المستخدم النهائي .. المقصود به الـ architecture الخاصة بالبرنامج .. كلما قللت من الأكواد كلما قلت الأخطاء.

ولكن باعتبار أن الـ Unit tests أنت من يكتبها لتختبر الكود الذي سيتم تشغيله عند المستخدم .. وأن هذه الـ Unit tests أيضاً هي للمبرمج وفقط فبالتالي فهذه القاعدة ليست سليمة .. ليست كل القواعد عامة في كل الأحوال. هنا خاص وهناك عام.

أنا لا أعرف ما وجه الاعتراض على الUnit Tests ؟؟ و اذا لم تكتب Unit Test كيف ستعرف اذا كان الكود الموجود عندك يؤدي أي وظيفة؟ و اذا غيرت تغيير و لو بسيط كيف يمكنك التأكد أن هذه التغيير لم يتسبب في كسر جزء اخر!!!

اقتباس

أنا لا أعرف ما وجه الاعتراض على الUnit Tests ؟؟ و اذا لم تكتب Unit Test كيف ستعرف اذا كان الكود الموجود عندك يؤدي أي وظيفة؟ و اذا غيرت تغيير و لو بسيط كيف يمكنك التأكد أن هذه التغيير لم يتسبب في كسر جزء اخر!!!

عندما يجلس يومين على الشاشة محاولاً تتبع ال Bugs (هذا إن كان محظوظاً و وجدها او لديه توثيق جيد) بعد Feedback سيئة من العميل

قصة جميلة ومعبرة للإجابة عن هذا السؤال من كتاب Pragmatic Unit Testing in C#

استخدم cut (c unit test system) فى السى و unittest فى البايثون .

بالنسبة للسوال عن ال coverage فانا استغربة, فهل هى معيار يدل على شى ؟

مادام انا الذى كتب الكود واعرف جيدا فائدة ووظيفة تلك الاجزاء فما الذى يهمنى فى نسبة ال coverage . اعتقد فائدتة الوحيدة هو متابعة الاجزاء التى تعمل من الكود فى الظروف المعينة و باى نسبة .

ارجو التوضيح ؟

واعتقد ان هناك اشياء يصعب كتابة لها كود unit testing فمثلا الكثير من اكواد الجرافيك لا يوجد خطاء فى الكود ولكن الفكرة فى ان logic الكود تحافظ على كفائتها فى الظروف المختلفة وهنا لن يظهر خطاء فى الكود لاقيسة بunit test بل كل شى سيمر بسلام . هناك امور تحتاج الى المراقبة بالعين . لذلك ارى هولاء يعتمدون بشكل كبير على اصدارات الاختبار المتتابعة لمعرفة ذلك (وقد يكون هناك ملفات معدة للتجريب فى حين نجاحها مع تلك الملفات يكون الكود اثبت نجاحة بشكل اولى رغم احتمال ظهور عيوب فيما بعد فى ملفات اخرى) . باختصار اقصد ان الكثير من البرامج قد يكون اختبارها اليدوى اسهل بمراحل عديدة من اختبارها بكود unit test (هذا ان امكن).

لم اقل ان الـ unit test بالضرورة هي من النوع السيء من الـ industry standards و لكن تعليقي كان على المنطق اللذي تحدثت من خلاله بشكل عام "يا ريت نبقى مثل بقية الناس الماشين على الستاندرد" و هذا ما كنت اعترض عليه.

و كذلك تشغيل عقلك لا يعني ان تضرب كل شيء بعرض الحائط :) و لكن يعني ان تشغل عقلك حين تقرأ و لا تقبل باي فكرة تسمعها لمجرد انك تظن او سمعت انها معيارية او مطبقة في الشركة الكبرى الفلانية او العلانية.

اقتباس

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

.... لا تعليق ...

motamayez كتب:

أنا لا أعرف ما وجه الاعتراض على الUnit Tests ؟؟ و اذا لم تكتب Unit Test كيف ستعرف اذا كان الكود الموجود عندك يؤدي أي وظيفة؟ و اذا غيرت تغيير و لو بسيط كيف يمكنك التأكد أن هذه التغيير لم يتسبب في كسر جزء اخر!!!

الاعتراض على المبالغة في اهمية وجوده في كل مكان!! البعض يريدك ان تكتب test مع كل function .. و هذا قمة الجنون!!

اما قصة Dale و صاحبه الاخر Pat، فالفكرة ابسط مما تتخيل و لا علاقة لها بالـ unit test بالذات، لا يوجد مبرمج ناجح الا و يختبر البرنامج باستمرار. يعني يكتب شيء جديد، يجربه (عمليا .. و ليس unit test)

اما ما يفعله Pat فمشكلته ليست لها علاقة بالـ unit testing بالذات، بل المشكلة ان Pat افندي يظن انه يستطيع ان يبرمج عن طريق كتابة صفحات و صفحات من الكود بشكل عمياوي ثم يحصل على برنامج ناجح!! اي شخص يفكر بهذا الاسلوب هو مبرمج فاشل (بل ليس مبرمجا اصلا لانه مستحيل انتاج اي برنامج بهذه الطريقة).

apex كتب:

بالنسبة للسوال عن ال coverage فانا استغربة, فهل هى معيار يدل على شى ؟

يدل نسبة التغطية على مدى تغطية الـ Unit Tests لكل المسارات في الكود الذي يتم اختباره. وهو معيار هام جداً وغالباً ما توضع نسبة معينة في المشروع الواحد ليسير عليها فريق العمل.

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

مثلاً كود نسبة تغطيته 50% .. وأخر نسبة تغطيته 90%

فمن المرجح أن الكود الذي تم اختباره وتغطية مساراته بنسبة 50% فقط لا يوثق به وقد يكون به أخطاء غير معلومة. أما الكود الذي تم اختباره وتغطية مساراته بنسبة 90% فبه درجة أمان عالية فقد تم اختبار أغلب مساراته والإطمئنان أنها تعمل كما يجب.

اقتباس

يدل نسبة التغطية على مدى تغطية الـ Unit Tests لكل المسارات في الكود الذي يتم اختباره. وهو معيار هام جداً وغالباً ما توضع نسبة معينة في المشروع الواحد ليسير عليها فريق العمل.

و هل تعتقد انه يمكن للـ unit test ان يغطي 100% من الحالات اللتي سيمر فيها الكود؟؟

hasan_aljudy كتب:

الاعتراض على المبالغة في اهمية وجوده في كل مكان!! البعض يريدك ان تكتب test مع كل function .. و هذا قمة الجنون!!

إذن أنا أشد الناس جنوناً في العالم!

وكل خبراء الـ Quality في العالم مجانين!

بل ومخترعي الـ Unit Test ومبادئه من باب أولى هو رأس الجنون كله!

ومؤلفي كتب الـ Unit Testing أيضاً .. كلامهم كله جنون في جنون!

أنا مجنون :D