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

جزء من كتاب Practical Software Factories in .Net اعجبنى و اردت ان اورده

اقتباس

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

مع استثناء انني لا اعمل في العالم العربي

اقتباس

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

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

اخ احمد عبد المنعم،

هذا البروسس (و الله لا اعرف كيف اترجم الكلمة للعربية هنا!) العقيم قد يبدو و كأنه يؤدي عمله لانه و كما تقول ان المنتج في الـ production .. و لكن هذه نظرة سطحية.

المنتج في حالة مزرية و لولا الـ process العقيم اللذي تفرضه الادارة لاصبح المنتج افضل عشرات المرات.

لا اعرف الشركة اللتي يتحدث عنها الاخ هويدي و لكني استطيع ان اتحدث عن مكان عملي.

كل عنصر من عناصر الـ process لدينا يبدو فكرة جيدة في حد ذاته، و لكن طريقة تطبيق هذه الافكار من دون تفكير حقيقي تؤدي الى كارثة.

مثلا:

اي كود يجب ان يكون له unit test -- فكرة تبدو جيدة

اي تغيير جديد يجب ان يكون تطبيقا لـ work item تحدده الادارة -- فكرة جيدة لكي يمكن معرفة ما هي التغييرات اللتي تضاف الى البرنامج

الاجزاء الحساسة من النظام و الـ infrastructure غير مسموح لاي احد تغييره، فقط مجموعة صغيرة تملك احداث تغييرات هناك -- ايضا تبدو فكرة جيدة من ناحية الادارة

لكن ما هي النتيجة اللتي تحصل عليها؟

- كود هش اي كلام -- لا احد يهتم بصيانة الكود و تحسينه لانه "يعمل" و لان هناك unit test لكي يثبت كفائته -- و لا احد يهتم بان الكود عبارة عن spaghetti او انه لا يحتوي على اي توثيق او انه معقد و غير مفهوم

- اذا رأيت كود هش و اردت اصلاحه لا يمكنك ذلك -- اولا لانه ليس من مهامك او مهام فريقك، ثانيا لان الادارة لم تسند اليك اي work item بهذا الخصوص، ثالثا لانك لست من المخولين باجراء اي تعديل.

- ربما يمكنك (نظريا) ان تتحدث الى احد من الادارة لكي تطلب منه ان يسند اليك هذا الـ work item و لكن العملية معقدة و غير مسلية

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

المحصلة إن الادارة تبحث دائما عن مبرمجين مهرة و لكن حين تضمهم الى الفريق تقيدهم و تمنعهم من تشغيل مهاراتهم -- اذن لا فائدة من تشغيل مبرمجين مهرة او البحث عنهم!!

اتمنى حقيقة ان لا ننسخ هذه الافة الى الشركات العربية بحجة انها "تؤدي عملها" في الشركات الغربية.

الشركات العملاقة تتطور ببطء و السبب هو في الادارة العقيمة.

الشركات الصغيرة تتطور بسرعة و لديها قدرة على الانتاج بكفائة تزيد عشرات المرات عن الشركات الكبيرة، و السبب هو عدم وجود سلسلة عقيمة من القيود على المبرمجين.

ما يفعله هذا الـ process هو قمع الابداع و تحويل المبرمج من فنان مبدع الى مجرد شخص ينفذ الاوامر.

اما ان هذا البروسس "ينجح في تأدية مهمته"، ربما .. اذا كانت مهمته هي "قمع الابداع من اجل تفادي حدوث اي كارثة"، و كما يقول بول جراهام: Big companies win by sucking less than other big companies.

ملحق: hackers and painters

When Yahoo bought Viaweb, they asked me what I wanted to do. I had never liked the business side very much, and said that I just wanted to hack. When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.

This seems to be the default plan in big companies. They do it because it decreases the standard deviation of the outcome. Only a small percentage of hackers can actually design software, and it's hard for the people running a company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design.

If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don't win by making great products. Big companies win by sucking less than other big companies.

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

اقول لك لا،

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

البروسس العقيم يمنع المبرمجين عادة من تحسين الكود، لهذا تجد اغلب الاكواد لا تزال في وضع أولي "يؤدي المهمة" و السلام.

اما زعمك:

اقتباس

الـ Process لم توضع في قالب بروسيس إلا بعد تجربتها ملايين المرات وأثبتت نجاحها بالفعل مع مبرمجين يعرفون جيداً ما هي البرمجة!

فهذا كلام فااااااااااضي

تتحدث و كأنك اصلا تعيش معنا في المكان اللذي نعمل فيه و تعرف ما هو الـ process اللذي نتبعه!!

اقتباس

الشركات العملاقة تتطور ببطء و السبب هو في الادارة العقيمة.

الشركات الصغيرة تتطور بسرعة و لديها قدرة على الانتاج بكفائة تزيد عشرات المرات عن الشركات الكبيرة، و السبب هو عدم وجود سلسلة عقيمة من القيود على المبرمجين.

ما يفعله هذا الـ process هو قمع الابداع و تحويل المبرمج من فنان مبدع الى مجرد شخص ينفذ الاوامر.

بغض النظر عن Unit tests ورأيك فيه ..

ولكن في الاسطر الثلاثة السابقة ، معك حق ..

لدرجة أني أحلم بأن أؤسس مؤسسة خاصة في يوم من الأيام حتى أكون حر من هذه القيود ..! :D .

بس بلاش كلمات حادة .. يمكن استبدالها بأوصاف أكثر أناقة .

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

الشمري كتب:

ولكن في الاسطر الثلاثة السابقة ، معك حق ..

لدرجة أني أحلم بأن أؤسس مؤسسة خاصة في يوم من الأيام حتى أكون حر من هذه القيود ..! :D .

نفس ما افكر فيه

لم أفهم ماهو اليونت تست !! داله تختبر داله أخرى ؟

لماذا ؟ لكي أقوم بتجربتها وتوضع بنفس البرنامج ؟ هل هذا صحيح ؟

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

أما داله للإختبار فأعتقد أنها تكون مفصوله عن البرنامج في مجلد آخر يتم الرجوع لها في حال أردت التعديل عليها , هذا ما أفعله عادة .... هل هو صحيح !!

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

برنامج صغير = جميع البرامج التي نعرفها

برنامج كبير = نظام تشغيل

اقتباس

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

شكرا على التوضيح.

اعتقد ان unit test اثبت فى مجال ال enterprise انة ال best-practice لانة يحقق اولياتها وعلى راسها الامان وما سبق سردة من الاخ احمد.

ولكن فى مجالات اخرى قد يكون الالتزام بالمعايير بشكل كبير يحد من تطور المشروع . فهناك الكثير من المشاريع الضخمة ولكن لها نسبة tester كبيرة تعتمد على المراجعة و اختبار نسخ الalpha و beta وبعضا من الunit-test (لكن غالبا تكون نسبتها ضئيلة بالنسبة لكود المشروع ) . وايضاء لو نظرنا للمشاريع التى تعتمد الاسلوب الاخر قد تجد الtester بالمئات واحيانا بالالاف والكثير منهم محترفين فى الاختبار .واظن ان تطبيق مبادى تطوير الenterprise مناسبة لمشاريع الenterprise لان يصعب عليهم الحصول على كل تلك النسبة من المختبرين .

من الحديث واضح الاختلاط بيم مفهوم ال Unit Testing الذى يقوم بكتابته المطور اثناء عمله و يستخدم على نطاق داخلى فى العمل و بين ال Black Box Testing بواسطة ال Alpha and Beta Testers

اقتباس

من الحديث واضح الاختلاط بيم مفهوم ال Unit Testing الذى يقوم بكتابته المطور اثناء عمله و يستخدم على نطاق داخلى فى العمل و بين ال Black Box Testing بواسطة ال Alpha and Beta Testers

بل اقصد ذلك .

هناك مشاريع ضخمة مطوريها يقوموا بمراجعة الكود(فى حالة كان جاء من مبرمج من خارج المشروع) و تجربتة بشكل اولى . ويتركون الbug-reporting للمختبرين.

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

طبعا لا اشجع هذا الدرجة من عدم الاختبار ولكن كنت اقصد فى المشاريع المفتوحة المصدر لا يكون الtesting بدرجة سطحية كالمعروف عن black-box ولكن هناك ادوات احترافية للاختبار وتتبع البرنامج و اتاحة log للdebugging وتتبع الكود و تحليل الاداء والخ . اعتقد انة ميزة من مميزات البرامج الopen source لان هولاء المختبرين يفعلون ذلك غالبا تتطوعا ولكى يحسنوا المشروع ويجب الاستفادة من عددهم و توفير مجهود المطورين .

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

اقتباس

هناك مشاريع ضخمة مطوريها يقوموا بمراجعة الكود(فى حالة كان جاء من مبرمج من خارج المشروع)

كيف ؟ هل يقوم بمراجعة سطور الكود اثناء التنفيذ سطر سطر ام يستخدم طريقة اخرى

السلام عليكم ...

قمت بكتابة unit testing toolkit بسيطة جداً باستخدام الـ Macros لاختبار مكتبة Range التي قمت بكتابتها منذ فترة. كانت تلك أول مرة أتبع طريقة اختبار كل دالة على حدة, و التالي هو ما استخلصته من التجربة:

السلبيات:

كتابة الـ Test Cases صعب. و الأصعب أن تفكر في جميع الاحتمالات.

لم أستخدم toolkit جاهزة و قوية كـ Boost.Test التي أنوي تعلمها و استخدامها في المستقبل إن شاء الله. و هذا سبب لي بعض الإحباط في كتابة الـ Test Cases.

الإيجابيات:

أصبح لدي فكرة أفضل, عن متى أستخدم assert و متى أستخدم exceptions و متى أكتب كود كـ unit test.

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

بعض الـ test cases كشفت عن بعض الأخطاء المنطقية, التي لم أكن أتوقع وجودها رغم تفاهتها بصراحة.

بالمناسبة, أعتقد أن معظم الأخوة قد فهموا كلام الأخ حسن بشكل خاطئ. الذي فهمته, هو أنه يقول أن الـ tests لا تغني عن الـ good design. و أنا أتفق معه في هذه النقطة.

تحياتي..

من فوائد ال Test Unit انها تساعدك فى عملية ال Refactoring كما اسلفت يا خالد

حسان يعتنق فكر ال Hackers و شغل ال Hacks للهواة و المتحمسين لكتابة الكود و ليس لإخراج منتج يستخدم بصورة أدمية

Khaled.Alshaya كتب:

الذي فهمته, هو أنه يقول أن الـ tests لا تغني عن الـ good design. و أنا أتفق معه في هذه النقطة.

بل الصحيح ..

الـ Good Design لا يخلو من الـ Unit Tests.

لماذا يتحامل الاخ احمد و متميز على حسان و يتحامل حسان على احمد و متميز من اجل فكرة

كل شخص حر برأيه نحن نتناقش و لا نفرض اراء

اقتباس

الـ Good Design لا يخلو من الـ Unit Tests.

أعتقد أن الـ Good Design أعم و أكبر من أن يتوقف على الـ unit testing.

هل تعتقد أن TEX مثلاً, لأنه لا يستخدم unit testing فهو سيء التصميم؟

أتحداك أن تجد bug واحدة فيه, و إن استطعت سيعطيك Knuth ما يعادل $327.68 على كل bug تجدها :)

أخي خالد ..

المشكلة أنه يوجد خلط لدى المناقشين هنا!

يظن البعض أن الكلام يعني .. أنه الـ Unit Test هو نهاية المطاف.

نحن نقول ...

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

بخصوص TEX فأنا لا أحب أن أتعالم وأتظاهر بمظهر الخبير ... أنا لا أعرف TEX أصلاً وقد يكون هذا لجهلي ... ولكن في النهاية أياً كان TEX أو غيره فهو برنامج مكتوب بأيدي بشر ولابد أنه به Bugs مهما كانت الاحتياطات اللازمة .. حتى وإن كان يوجد به Unit Tests.

انظر فأنا لم أدع أن وجود Unit Tests يمنع الـ Bugs ولكني أجزم أنه يحميك منها بنسبة كبيرة.

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

حسان يعتنق فكر ال Hackers و شغل ال Hacks للهواة و المتحمسين لكتابة الكود و ليس لإخراج منتج يستخدم بصورة أدمية

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

بالنسبة لي الـ hacker يهتم بجودة المنتج اكثر من ارباب العمل ..

اخ احمد عبد المنعم، انت قلت بنفسك ان الـ Unit Test تغني عن الـ documentation!! و ايضا اصررت بشدة على انها افضل ضمان لجودة و كفائة الكود، و هذا التفكير سيقودك بوعي او بدون وعي الى الاهتمام بالـ unit testing اكثر من اهتمامك بالكود نفسه.

بالنسبة لي الـ unit test يجب ان يكتب بعد كتابة الكود و بعد التأكد من ان الكود يعمل .. و ذلك من اجل التأكد من عدم حصول regressions في المستقبل.

اما اعتبار الـ unittesting كبديل عن التوثيق و ضامن للجودة في حد ذاته .. فهذه فكرة خاطئة و اظن اصلا انه حتى اعتى مشجعي الـ unit testing لا يدعمون هذه النظرة.

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

اقتباس

اخ احمد عبد المنعم، انت قلت بنفسك ان الـ Unit Test تغني عن الـ documentation!! و ايضا اصررت بشدة على انها افضل ضمان لجودة و كفائة الكود، و هذا التفكير سيقودك بوعي او بدون وعي الى الاهتمام بالـ unit testing اكثر من اهتمامك بالكود نفسه.

أنا لم أقل أن الـ Unit Tests تغني عن الـ Documentation نهائياً في هذا الموضوع .. إنما قلت أنها هي نفسها لا تحتاج إلى Comments لأنك لو كتبتها بطريقة صحيحة لن تحتاج لتوثيق. أرجو التركيز في كلامي جيداً قبل أن تقولني ما لم أقله!

وربما لأنك لا تعرف ما هي ال Unit Testsأصلاً لا تعلم ما حجم التطوير والقوة التي تضاف للكود وللـ Architecture والتصميم العام للبرنامج فهو يصبح أكثر Extensibility و أكثر طواعية .. وأسهل في الصيانة .. بل وأقوى في الكفاءة.

اقتباس

بالنسبة لي الـ unit test يجب ان يكتب بعد كتابة الكود و بعد التأكد من ان الكود يعمل .. و ذلك من اجل التأكد من عدم حصول regressions في المستقبل.

هل سمعت من قبل عن Test Driven Development؟ وهل سمعت من قبل أن كتابة الـ Test أولاً من أحد أفضل الـ practices الآن في العالم وتقوم عليها مثلاً Process مثل XP بل ومعظم الـ Agile Processes؟ بالمناسبة أنا أستخدم هذا الأسلوب وينتج لي أكواد بكفاءة عالية.

اقتباس

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

كلام لا يمكن أن يصدر من مبرمج محترف!

اقتباس

أنا لم أقل أن الـ Unit Tests تغني عن الـ Documentation نهائياً في هذا الموضوع .. إنما قلت أنها هي نفسها لا تحتاج إلى Comments لأنك لو كتبتها بطريقة صحيحة لن تحتاج لتوثيق. أرجو التركيز في كلامي جيداً قبل أن تقولني ما لم أقله!

اها .. طيب اذن، يبدو اني فهمتك غلط. آسف!

اقتباس

هل سمعت من قبل عن Test Driven Development؟ وهل سمعت من قبل أن كتابة الـ Test أولاً من أحد أفضل الـ practices الآن في العالم وتقوم عليها مثلاً Proccess مثل XP

نعم سمعت بالـ TDD و سمعت بهذا الرأي اللذي تقول عنه انه "افضل practice في العالم"!!

و انا لا اتفق معه مطلقا.

اقتباس

كلام لا يمكن أن يصدر من مبرمج محترف!

كيف يعني؟

لا يمكن لاي مبرمج ان يخالفك الرأي؟

اقتباس

نعم سمعت بالـ TDD و سمعت بهذا الرأي اللذي تقول عنه انه "افضل practice في العالم"!!

أنا قلت من أحد أفضل الـ practices في العالم ولم أقل أفضل بإطلاق فأنا لست واعياً لما أقول! .. وهذا يعني أن هناك debates كثيرة جداً في هذه النقطة ولكنها تدور حول نكتب ال Unit Tests أولاً .. أم ثانياً ... ولا تدور أبداً على إهمال ال unit tests كما تقول! فانظر الفارق.

اقتباس

كيف يعني؟

لا يمكن لاي مبرمج ان يخالفك الرأي؟

يا أخي خالفني بعلم وبحجة ومنطق .. ولا تقل لي وجهة نظري وتقف!

وجهة نظرك إن كانت مبنية على علم فأهلاً بها ومرحباً ..

وجهة نظرك إن كانت مخالفة للعالم أجمع ولكن مبنية على علم وليس هوى شخصي فهي تحترم ...

لكن أن تعارضني فقط لتعارضني ثم تقول لي هذه وجهة نظري .. فهذه وجهة نظر لا يؤخذ بها في الإطار والنقاش العلمي.

اقتباس

ولا تدور أبداً على إهمال ال unit tests كما تقول!

انا لم اقل نهملها تماما كما تظن .. يا اخي افهم وجهة نظري جيدا قبل ان تحاججني.

اقتباس

يا أخي خالفني بعلم وبحجة ومنطق .. ولا تقل لي وجهة نظري وتقف!

عزيزي، "العالم كله هكذا" ليس بحجة ولا علم ولا منطق!

بل في بعض الاحيان، كون اسلوب معين متبع في كثير من الشركات الكبيرة، قد يكون دليلا على انه اسلوب عقيم (لاحظ .. "بعض الاحيان"، و "قد" .. لكي لا تسيء الفهم)

و على كل حال، الفكرة بسيطة جدا:

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

قكما ترى ليس هناك علاقة لا تناسبية ولا تطاردية بين كمية الـ unit tests و بين جودة المنتج.

و لهذا قلت: الطريقة الوحيدة لضمان الجودة هي تجريب البرنامج بشكل عملي و وضعه تحت الظروف اللتي سيضعه فيها المستخدمين.

و هذه بديهية اصلا .. لا اظن ان احد يمكن ان يختلف معها!! و اذا كان لديك مصدر معتبر يخالف هذا الموقف فهاته و لنرى!

و هذا الرأي بالطبع ليس من اختراعي بل سمعته و قرأته كثيرا .. اظن حتى من لينوس تورفلدز (و ان كنت لا اتذكر المصدر)

اقتباس

عزيزي، "العالم كله هكذا" ليس بحجة ولا علم ولا منطق!

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

أما:

اقتباس

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

قكما ترى ليس هناك علاقة لا تناسبية ولا تطاردية بين كمية الـ unit tests و بين جودة المنتج.

إذن العيب في العمل عندك .. وليس في الـ Unit Tests. انظر من يكتب هذه الـ Unit Tests ومن يكتب الأكواد .. لترى أين العيب بالفعل!

اقتباس

و لهذا قلت: الطريقة الوحيدة لضمان الجودة هي تجريب البرنامج بشكل عملي و وضعه تحت الظروف اللتي سيضعه فيها المستخدمين.

و هذه بديهية اصلا .. لا اظن ان احد يمكن ان يختلف معها!! و اذا كان لديك مصدر معتبر يخالف هذا الموقف فهاته و لنرى!

حتى هذه لها قواعد وتدور بين رحى الـ Unit Testing والـ Testing عن طريق فرق الـ QC. وليس أن تفتح البرنامج وتدوس على هذا وتأتي بهذا وتقول لي هذا تجربة البرنامج عملياً هذا يسمى في المصطلح بالـ Monkey Testing (أنا لا أسب أستغفر الله بالفعل هذا اسم هذه الطريقة). لكل شيء أصول وقواعد!

اقتباس

إذن العيب في العمل عندك .. وليس في الـ Unit Tests.

أكيد .. و كما سبق و قلت، احد اسباب العيوب هي اتباع "اساليب" و "قواعد" و "معايير" دون تفكير، بل تطبيقها بشكل سيء جدا (ولا احد يهتم!) لان هم الادارة فقط ان يقال "نحن نتبع الـ best practice"، و كأن الهدف هو فقط اخلاء المسئولية: ما دمت امشي مع الاساليب المتبعة فلا يمكن ان يلومني احد اذا حصلت مشاكل.

اقتباس

وليس أن تفتح البرنامج وتدوس على هذا وتأتي بهذا وتقول لي هذا تجربة البرنامج عملياً

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

كلمتان فقط: beta testing

هذا هو السبب بالفعل:

اقتباس

تطبيقها بشكل سيء جدا

وليس السبب اتباع الأساليب الحديثة .. فلا تلقي اللوم عليها وألق اللوم على من لا يستطيع استخدامها.

اقتباس

فلا تلقي اللوم عليها وألق اللوم على من لا يستطيع استخدامها.

من البداية لم القي اللوم على اسلوب معين، بل القيته على عقلية "هذه هي المعايير"، و كأن المعايير هي خطوات تتبع بشكل عمياوي 1, 2, 3 لتحصل على جودة عالية و منتج رائع يجني لك الكثير من الارباح!

كثيرا ما ينسى الناس ان هذه الاشياء وضعت كعوامل مساعدة و ان العامل الاول و الاخير و الاهم من كل تلك المعايير هو العقل و من لا يشغل عقله لن تفيده اية معايير.

بمعنى آخر، اذا فكرت باسلوب "هذه هي المعايير العالمية و يجب ان نتبعها" فإنك لا محالة ستقع في فخ التطبيق السيء.