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

hasan_aljudy كتب:

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

يا سيدي الفاضل أنا لا أتكلم بدون خبرة أو بدون تجربة وعندما أجد نفسي لا أعلم شيء عن الأمر المطروح لا أتحدث ولا أتفلسف كثيراً.

في البداية يجب أن تعلم أن هذه الأرقام ما هي إلا Indicators ولكن لا يجب أن يؤخذ عليها قرارات أو أن يعول عليها كثيراً. بمعنى أخر: Tests coverage metrics can tell you what code is not tested, but cannot accurately tell you what code is tested.

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

وبالنسبة لسؤالك .. نعم يمكن ذلك وبكل كفاءة إن أردت أنت أن يكون كذلك .. فهي نقطة تخضع لمتطلبات المشروع .. وكثيرة من العوامل .. بالنسبة لي نعم .. أحصل على 100% تغطية كاملة لأكوادي .. لأنني أعمل بطريقة Test Driven Development والتي تسهل عليك هذا الأمر لأنك لا تكتب أي Production code إلا الذي يقوم بإصلاح الاختبار المتعطل وفقط.

اخي احمد هل يوجع رابط او كتاب يشرح ذلك

تشوقت :)

نعم أفضل كتب قرأتها في هذا المجال Pragmatic Unit Testing in C# و Art of unit testing

هل Testing بشكل عام و Unit Testing بشكل خاص ، يدخل ضمن الـ documentation للمشروع بعد الانتهاء منه ؟ هل يتم توثيقه خارج المشروع ؟ كيف تخبر من حولك أنك اختبرت مشروعك - في مشروع جماعي - ؟ كيف تتفادى التعارضات مع شخص آخر يعمل معك اذا كنتما تعملان على جزئيات متقاربة ؟ قد يحصل تكرار في بعض الجوانب المشتركة مثلاً .

خليني اوضح نقطة: اذا كنت تعتقد ان الـ unit test يمكن ان يختبر كل شيء فأنت واهم .. و واهم جدا!! و هذا بالضبط ما اعنيه حين اقول اتمنى ان نشغل عقولنا قليلا ...

الـ unittesting له فوائد .. و لكنه ليس كل شيء، و يجب ان تكون واعيا لهذه الحقيقة، و لا توهم نفسك ان الكود "مضبوط 100%" لمجرد انه خاضع للعديد من الـ unittests

نقطة اخرى مهمة ايضا (و هنا سيتهمني البعض بالكسل ..) و هي ان كتابة الـ unittests عملية مملة كما يعرف الجميع، فإذا كنت تزعم انها ضرورية لكل function فمن الافضل ان تريني دليلا على ذلك بدل الاختباء وراء "معايير" عالمية او "الكتاب الفلاني فند كل اقوالك من زمان"، فانا لست مستعدا ان اعذب نفسي لكي ارضي شخص يتفلسف بالمعايير ..

ايضا لو كتبت عدة اختبارات لكل فنكشن سيصبح الكود جامد و صعب التغيير .. لانك كل ما تريد تغير فنكشن او تضيف او تحذف فنكشن يجب ايضا ان تغير او تضيف او تحذف التست الخاص به ..

لا شكرا .. لست مستعدا ان اضع نفسي تحت هذه الضروف لمجرد ارضاء كتاب او معيار ..

ما هي الفكرة اذن؟

- نعم لها فوائد، لكن لا داعي لتضخيم هذه الفوائد و اعطائها اكبر من حجمها الحقيقي

- عملية مملة جدا و لها مشاكل اخرى مثل صعوبة الصيانة و تصعيب التغيير اذا تم استخدامها بشكل زائد عن الحد

و لهذا يجب البحث عن نقطة توازن، و هذه النقطة هي في الاقتصاد في الـ unittests و توفيرها فقط للاجزاء الضرورية من البرنامج.

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

الشمري كتب:

هل Testing بشكل عام و Unit Testing بشكل خاص ، يدخل ضمن الـ documentation للمشروع بعد الانتهاء منه ؟ هل يتم توثيقه خارج المشروع ؟ كيف تخبر من حولك أنك اختبرت مشروعك - في مشروع جماعي - ؟ كيف تتفادى التعارضات مع شخص آخر يعمل معك اذا كنتما تعملان على جزئيات متقاربة ؟ قد يحصل تكرار في بعض الجوانب المشتركة مثلاً .

الـ Testing بشكل عام وما يقوم به فريق التحكم في الجودة أو Quality Control له أظن مستنداته كالـ Test Plan وغير ذلك .. ولكني لا أعرف الكثير في هذه النقطة فمن الممكن أن يكون الأمر مختلف عما قرأته.

أما الـ Unit Testing .. فلم أسمع مرة أنه يوجد Documentation له مع المشروع لأنه هو نفسه يعتبر Documentation بمعنى أن طريقة كتابة الدالة التي تختبر دالة تجعلها في حد ذاتها مقروءة جداً وهذا يعود للخبرة في هذه الأمور ومن الممكن أن يكتب شخص أخر الـ Test Cases كلها على ورق .. أعتقد أنها راجعة للشخص أو المشروع ... إلخ ولكن لم يصادفني مرة Standard أو طريقة معينة ذلك بل ولم أسمع أيضاً بها.

في العادة .. المشروعات الجماعية لا يأخذ كل فرد مشروع منفصل .. من الممكن أن أخذ Class وزميلي Class .. أو دالة ودالة .. أو غير ذلك هذه ليست القضية .. النقطة الآن هل سيحدث تعارض .. هذا يرجع إلى كيفية توزيع العمل هذا أولاً. ثانياً هذه نقطة تجعلنا نتطرق للـ Source Control tools وهي بعيدة عن مجال النقاش الآن ولكن بطريقة أو بأخرى تستطيع أدوات التحكم في الكود أن تحدد أماكن الـ Conflict وتحلها أيضاً لو وجدت وكانت سهلة الحل أو تعطيك الأدوات اللازم لحل التعارض بين شخصين قاما بالعمل على ملف واحد مثلاً.

لا أعلم هل هذه إجابة السؤال أم أنني خرجت خارج الموضوع.

أنا الصراحة متفاجئ جداً من الثقافة الغريبة عن الUnit Tests عند البعض, ليس لدي مشكلة أنك غير مقتنع بالUnit Testing لكن لا تحاول أن تثبت أن هذا شئ من الاحترافية بالترفع عن كتابة الUnit Test فهذا هو نوع المبرمجين الذي ينتهي بهم الامر بتدمير المشاريع.

الUnit test هي الطريقة الوحيدة (حتى وقتنا هذا) لاثبات أن ما كتبته من كود له أي معنى, غير هذا فهو مجرد كلام لا يمثل أي شئ, كما أن كل سطر تكتبه هو مشكلة حتى يثبت العكس.

كما أننا لا نتكلم عن مشاريع تعمل بها وحدك, لو كنت تعمل في مشروع فيه عدد من المبرمجين فعدم كتابة Unit test هو ببساطة تدمير للproductivity لأنك ستجد عائق ضخم أمامك لتغيير كود كتبه مبرمج غيرك فلا يوجد لديك وسيلة للتأكد من أنك لم تغير وظيفة البرنامج بتغييرك هذا السطر أو تلك الدالة.

اقتباس

لكن لا تحاول أن تثبت أن هذا شئ من الاحترافية بالترفع عن كتابة الUnit Test فهذا هو نوع المبرمجين الذي ينتهي بهم الامر بتدمير المشاريع.

لا احاول اثبات شيء .. كل ما افعله هو طرح وجهة نظر مخالفة لما تتداوله "الكتب".

ليست قضية ترفع و لكن اثبت لي انها تستحق اضاعة وقتي عليها و اذا اقتنعت ساقوم بكل سرور بكتابة عشرين تست لكل فنكشن.

أعتقد أن الموضوع دخل لمنعطف موش مظبوط!

السؤال بسيط بدون استخدام الUnit Test

1- كيف تتأكد أن السطر الذي كتبته الأن يقوم بما تعتقد أنه يقوم به؟؟؟

2- كيف يمكنك حماية برنامجك من أن يقوم مبرمج عن خطأ أثناء تغيير جزء في البرنامج لأي سبب من أن يقوم بكسر جزء اخر في البرنامج؟؟

motamayez كتب:

السؤال بسيط بدون استخدام الUnit Test

1- كيف تتأكد أن السطر الذي كتبته الأن يقوم بما تعتقد أنه يقوم به؟؟؟

2- كيف يمكنك حماية برنامجك من أن يقوم مبرمج عن خطأ أثناء تغيير جزء في البرنامج لأي سبب من أن يقوم بكسر جزء اخر في البرنامج؟؟

1- كيف أتأكد؟؟ هل انت جاد؟؟ طبعا عن طريق تجريب البرنامج!!!

2- عن طريق مراجعة التغييرات و التأكد من المبرمج الاخر يعرف ماللذي يفعله ..

ربما السؤال كيف يمكن تغيير اي شيء في البرنامج اذا كان كل فنكشن عليه يونت تست؟؟ يجب حتما تغيير الـ unit test عند تغيير الفنكشن (تيتي تيتي مثل ما رحتي مثل ما جيتي)

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

(ملاحظة: يرجى وضع هذه المشاركة في اطار مشاركاتي السابقة)

اقتباس

1- كيف أتأكد؟؟ هل انت جاد؟؟ طبعا عن طريق تجريب البرنامج!!!

وال unit testing نوع من أنواع تجريب البرنامج (testing )

اقتباس

ربما السؤال كيف يمكن تغيير اي شيء في البرنامج اذا كان كل فنكشن عليه يونت تست؟؟ يجب حتما تغيير الـ unit test عند تغيير الفنكشن (تيتي تيتي مثل ما رحتي مثل ما جيتي)

أنت غيرت الدالة, لذا ال unit test القديم لم يعد ناسبها, لذا عليك القيم ب"تجريبها" أليس كذلك؟؟

اقتباس

1- كيف أتأكد؟؟ هل انت جاد؟؟ طبعا عن طريق تجريب البرنامج!!!

يا سلام و الله لم أعرف هذا, يا أخي لو كنت تجادل من أجل الجدال فهذا شأنك, لكن اذا كنت تريد أن تتعلم ففكر قبل أن تكتب

ماذا لو برنامجك لا يوجد له User Interface أو برنامجك يحتاج الى Deployment قد تحتاج لساعات أو أن الكود الذي تكته هو جزء من نظام ضخم و ما تعمل عليه هو مكتبة واحدة في هذا النظام؟؟؟

يبدو أن أكبر برنامج كتبته هو 10 اسطر

اقتباس

2- عن طريق مراجعة التغييرات و التأكد من المبرمج الاخر يعرف ماللذي يفعله .

Be My Guest

اقتباس

يبدو أن أكبر برنامج كتبته هو 10 اسطر

إخي ممتاز, إمسك أعصابك شويه, مينفعش الكلام ده.

متقولو حاجه ياخونا

اقتباس

لا أعلم هل هذه إجابة السؤال أم أنني خرجت خارج الموضوع.

بالعكس ، أجبت عن السؤال بالتفصيل ، شكراً لك أخي.

اخ متميز، تذكر ما تجادلني حوله: انا قلت ان هناك حالات نحتاج فيها unit testing و لكن ليس معنى هذا ان نكتب تست لكل فنكشن. انت تزعم ان كل فنكشن مهما كان يجب ان يكون له unittest

اذا كنت تكتب جزء من نظام ضخم و لا توجد طريقة للتأكد من صحة ما كتبته بأي طريقة غير الـ unit test فـ be my guest .. هذه احدى الحالات اللتي تحتاج فيها الى unit testing و انا لم انكر عليك ذلك.

لكن ليست كل الحالات هي من تلك النوع.

لاحظ ايضا انني حين اقول انني لا اكتب العديد من الـ unit tests فانا اتحدث عن مشاريعي الخاصة و اللتي هي طبعا ليست مكتبات او سرفرات

اقتباس

يبدو أن أكبر برنامج كتبته هو 10 اسطر

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

و هذا ليس ببعيد جدا عن لب الموضوع .. تحسين الكود في كثير من الاحيان ياتي بنتائج افضل من مجرد ارفاق test مع كود اي كلام.

ازيدك من الشعر بيتا .. النظام اللذي نعمل عليه في العمل مليان كود "اي كلام" مع الكثير الكثير من الـ unit tests .. و هناك الكثير الكثير ايضا من الكود (ايضا كود اي كلام) من دون اي tests

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

هل تلاحظ ما ارمي اليه؟؟

الخطأ اللذي يقع فيه البعض، اضافة الى اعتقادهم ان كل شيء يجب ان يكون له unit test، هو اعتقادهم ان الـ unit test لوحده كافي لاثبات كفائة الكود!! و هذا تفكير خطير لانه يؤدي الى كتابة كود اي كلام بحجة ان هناك unit test يغطي الكود و يضمن موثوقيته!!

لا داعي ايضا لان اذكرك و اذكر الجميع انه لا يمكن للـ unit test ان يختبر كل شيء .. يمكن ان تتخيل العديد من السيناريوهات اللتي ممكن ان تخرب الكود .. لكن لا يمكنك الاحاطة بها جميعا. و حتما من كل بد، ستظل هناك علل و اخطاء لا يكشفها الا الاستخدام الفعلي للبرمجية بشكل عملي. عندئذ ماذا ستفعل حين تكتشف حالة جديدة تخرب الكود و ليس لها test؟؟ ستقول لي: بسيطة، نكتب تست جديد!! ساقول لك طيب، و لكن يجب اولا ان تصلح الـ bug !!!

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

و هذه ليست مجرد فرضيات اخترعتها من عندي بل مواقف واجهتها بالفعل في العمل. كل شي يمشي حسب process عقيم و معايير "السوق"، من دون تفكير فعلي، كل شي by the book، و النتيجة هي كود من اسوأ ما رأيت في حياتي. و انا لا الوم المطورين بل الوم الـ process العقيم اللذي تتبعه الادارة، و اللذي هو نتيجة مباشرة لطريقة التفكير اللتي انتقدتها منذ بداية الموضوع، الا وهي اتباع "المعايير" من دون تفكير. فلا احد يعمل في بيئة كهذه يستطيع انتاج كود جيد.

و بالنتيجة حين اواجه bug report و احاول اصلاحه، اجد نفسي مضطرا الى زيادة الكود تعقيدا و هشاشة، لماذا؟؟ هكذا هو الـ process و هذه هي المعايير!! و ربما اترك التفاصيل لموضوع آخر.

من وجهة نظرى الشخصية

ال Unit Test هامة لاختبار الاجزاء الاساسية من اى تطبيق و ليس كل الدوال و المعطيات الموجودة إلا فى حالات الانظمة التى تعمل طوال الوقت فهنا وقفة و يجب النظر لل Test بصورة افضل

ال Unit Test تفيد فى عملية ال Requirement Validation للمكتبات بمعنى لدى فئة مفترض بها القيام ب 3 وظائف (التأكد من وجود المستخدم - التحقق من المستخدم - تسجيل الدخول )

بمرور الوقت و تحت ضغط العمل ربما يطلب مديرك من شخص اخر ان يضيف دالة لهذه الفئة او تقوم انت بالاضافة او بتعديل جزء من الكود بدون ان يكون هذا متوافراً فى ال Design Paper

فائدة ال Unit Test انها تنبأك بأن التصميم لا يتناسب مع ال Implementation

الاعتمادية Dependency : انت تقوم بكتابة تطبيق يعتمد كل موديول على موديول اخر او فئة على فئة اخرى نفترض ان احد الفئات لم يتم عمل Implementation لها حتى الان فكيف ستقوم باختبار تطبيقك ؟ اعتقد انك ستفكر فى ال Mocking

ال TDD كمفهوم اكبر من مجرد كتابة كود لاختبار قطعة كود و انما هى قطعة فنية لا تراها إلا عندما تكتسب خبرة كتابة Solid Tests لبرنامجك و النظر من اعلى لل Testing

ببساطة ال Unit Test هى خيار متاح تود ان تستخدمه استخدمه لا تود فأنت تتحمل مسئولية قرارك

أما أنا يا أخي متميز لا أستغرب من الثقافة التي أراها الآن .. وكلنا يعرف لماذا طبعاً! أو على الأقل أنا بس!

المهم ..

من قال في الموضوع كله من أوله لأخره أن الـ Unit Test هو كل شيء وأنه يختبر كل شيء وأنه نهاية العالم؟! الـ Unit Test هي أداة يتأكد بها المبرمج أن كوده يعمل ويتأكد بها المبرمج الأخر أنه عند تغيير الكود ونجاح التست فهذا لم يكسر جزء أخر في البرنامج أو لم يغير في الـ Requirements الأساسية. أما أن هناك اختبارات أخرى فهذا لا يخفى على جاهل أصلاً فضلاً عن عالم. هناك عدة Tests أخرى هامة جداً يقوم بها فريق الـ QC وليس نحن. فنحن لسنا Testers. ولهذا ما نكتبه في ناحية الـ Testing فقط هي الـ Unit Testing ولا يكتبها أبداً الـ QC.

يقال أن العيب في الـ Process العقيمة .. وليس في المبرمجين!

أنا أقول طبعاً العيب في المبرمجين الذين لا يعرفون ماذا يفعلون ... ولا يقرأون .. ولا يتعلمون .. ويكتبون أكواد يكتبها عيل في أولى حضانة برمجة! .. الـ Process لم توضع في قالب بروسيس إلا بعد تجربتها ملايين المرات وأثبتت نجاحها بالفعل مع مبرمجين يعرفون جيداً ما هي البرمجة! فإلقاء اللوم على الـ Process بالطبع كلام لا ينظر إليه إلا بعين الشفقة.

اقتباس

فهذا لا يخفى على جاهل أصلاً فضلاً عن عالم.

يا أخي, ال process أحيانا تكون نقمه على من يعمل بداخلها, أنت فقط لم تجرب أن تعمل داخل process صارمه (عقيمه ) بمعني الكلمه.

أنا مثلا أعمل في بيئة نقوم فيها بعمل صيانه و تطوير لخادم payments مشهور (يقوم ب 25% من نسبة ال payments على مستوي العالم)

هذا الخادم في الإنتاج منذ فتره كبيره (أكثر من عشر سنوات على ما أعتقد)

لذا ستجد ال process عندنا حساسه جدا, حرف الكود تغير قد يجعلك تنتظر يوم كامل من قبل أن تتهور و تقوم بكتابته + إياك أن تقوم بعمل تغير غير المطلوب منك بالحرف + قم بعمل أقل أقل أقل تغير للوصول لحل المشكله الموجوده+ إياك أن تغير في كذا أو كذا + إياك أن تفعل كذا + و حاجات غريبه كتير من هذا القبيل... :D

أخي هويدي ..

عذراً .. فهذه الـ Process .. من وضعها يفهم جيداً في عالم البرمجة وله خبرة جيدة في نظري.

أليس هذا المنتج في الـ Production الآن؟! فما العجب .. أحسن والله من وضع هذه الـ Process ...

أتريد أن يكتب أي أحد أي شيء لأنه يظن أنه مبدع ثم يقع ما لا يحمد عقباه وتخسر الشركة! طبعاً لا.

أرأيت .. الـ Process ليست المشكلة .. المشكلة في تفكير المبرمجين داخل الـ Process .. أنت تريد أن تنطلق مثل أي مبرمج .. ولكن حظك العسر أنك تخدم منتج في الـ Production .. الخطأ ليس من الـ Process .. عليك أن تعلم أنه الحذر الحذر الحذر في مثل هذه الأمور.

ولكن هذه قضية أخرى غير التي نتكلم فيها .. إن ما يتم التحدث عنه أن الـ Process التي يضعها البعض من أجل حماية البرنامج باستخدام الـ Unit Tests .. فهي عقيمة! :D والله أضحكتني جداً!

وفي النهاية هذا لا يعني أن كل الـ Processes صحيحة في الحالات التي تطبق فيها. المشكلة ليست أيضاً في الـ Process المشكلة في من يطبقها وفي أي حالة. ليست كل Process ناجحة في كل الحالات.

في النهاية والخلاصة:

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

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

يا أخي أي مبرمج في بداية حياته يحتاج أن يخطأ و يجرب و يكتب و يبرمج ليتعلم البرمجه أكثر من تعلمه أي شئ أخر (مثل ال process مثلا)

أنا هنا لا أقلل من أهميه تعلم المبرمج (الذي حتما سيصبح قائد ثم مدير إلخ) لل process , لكن لنا معشر المبرمجين, فإن تعلم البرمجه أهم 100 مره

فوجود process كالتي تحدثتُ أنا عنها, فهي تجعلك منك مبرمج مع وقف التنفيذ!

إذا فهي ليست جيده لي, و لكنها جيده لأرباب العمل. فأنا معك في هذه النقطه.

شكرا على ردك

نعم أخي هويدي .. كلامك صحيح من وجهة نظرنا كمبرمجين ..

ولكن عندما تتحول البرمجة إلى صناعة .. فالأمر يتغير تماماً والمعايير تختلف.

الموضوع ليس لاقناع اشخاص بافكار معينة و انما هو استفتاء و نقاش لما يجرى مع المبرمجين العرب و بالتالى انعكاس المستوى على الصناعة فى العالم العربى ككل

اقتباس

ا أخي أي مبرمج في بداية حياته يحتاج أن يخطأ و يجرب و يكتب و يبرمج ليتعلم البرمجه أكثر من تعلمه أي شئ أخر (مثل ال process مثلا)

أنا هنا لا أقلل من أهميه تعلم المبرمج (الذي حتما سيصبح قائد ثم مدير إلخ) لل process , لكن لنا معشر المبرمجين, فإن تعلم البرمجه أهم 100 مره

فوجود process كالتي تحدثتُ أنا عنها, فهي تجعلك منك مبرمج مع وقف التنفيذ!

إذا فهي ليست جيده لي, و لكنها جيده لأرباب العمل. فأنا معك في هذه النقطه.

هذا هو الفرق بين المبرمج Programmer و المطور Developer

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

الموضوع ليس لاقناع اشخاص بافكار معينة و انما هو استفتاء و نقاش لما يجرى مع المبرمجين العرب و بالتالى انعكاس المستوى على الصناعة فى العالم العربى ككل

+ مليون

ولا مانع من أن يقتنع أي فرد بأن هذا هو الـ Best practice في تطوير البرمجيات أيضاً حتى نرتقي بمستوى البرمجيات العربية!

اقتباس

عندئذ ماذا ستفعل حين تكتشف حالة جديدة تخرب الكود و ليس لها test؟؟ ستقول لي: بسيطة، نكتب تست جديد!! ساقول لك طيب، و لكن يجب اولا ان تصلح الـ bug !!!

عليك كتابة Test للتأكد من سلامة ال Functionality الحالية و كى تتأكد ايضاً انه بعد اصلاحك ال Bug فى المرحلة الثانية لن تقوم بكسر اى Functionality

انصحك بقراءة كتاب (Working Effectively with legacy code)

الكود الذى لا يوجد له Unit Test يسمى Legacy Code

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