ما الذي لا يجب اختباره عندما يتعلق الأمر باختبار الوحدة؟
https://stackoverflow.com/questions/109432
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
في أي أجزاء من وحدة كتابة المشروع تكون اختبارات الوحدة شبه مستحيلة أو مستحيلة حقًا؟الدخول الى البيانات؟بروتوكول نقل الملفات؟
إذا كان هناك إجابة على هذا السؤال فإن التغطية بنسبة 100% هي أسطورة، أليس كذلك؟
المحلول
هنا لقد وجدت (عبر اخترق شيء يقول مايكل فيذرز يمكن أن يكون إجابة:
هو يقول،
لا يعد الاختبار اختبارًا للوحدة إذا:
- يتحدث إلى قاعدة البيانات
- ويتواصل عبر الشبكة
- يمس نظام الملفات
- لا يمكن تشغيله في نفس الوقت الذي يتم فيه إجراء أي من اختبارات الوحدة الأخرى
- يجب عليك القيام بأشياء خاصة ببيئتك (مثل تحرير ملفات التكوين) لتشغيلها.
ويضيف مرة أخرى في نفس المقال:
بشكل عام، من المفترض أن تكون اختبارات الوحدة صغيرة، فهي تختبر طريقة ما أو تفاعل طريقتين.عندما تقوم بسحب قاعدة البيانات، أو المقابس، أو الوصول إلى نظام الملفات إلى اختبارات الوحدة الخاصة بك، فإنها لم تعد تتعلق بهذه الأساليب بعد الآن؛إنها تتعلق بتكامل التعليمات البرمجية الخاصة بك مع هذا البرنامج الآخر.
نصائح أخرى
إن التغطية بنسبة 100% هي أسطورة، وهي كذلك، ولا تعني أن التغطية بنسبة 80% عديمة الفائدة.الهدف بالطبع هو 100%، وبين اختبارات الوحدة ثم اختبارات التكامل، يمكنك الوصول إليه.
ما هو مستحيل في اختبار الوحدة هو التنبؤ بكل شيء بشكل كامل غريب الأشياء التي سيفعلها عملاؤك بالمنتج.بمجرد أن تبدأ في اكتشاف هذه الانحرافات المحيرة للعقل في التعليمات البرمجية الخاصة بك، تأكد من إعادة اختباراتها مرة أخرى إلى مجموعة الاختبار.
دائمًا ما يكون تحقيق تغطية التعليمات البرمجية بنسبة 100% أمرًا مهدرًا.هناك العديد من الموارد حول هذا الموضوع.
لا يوجد شيء مستحيل لاختبار الوحدة ولكن هناك دائمًا عوائد متناقصة.قد لا يكون من المفيد اختبار الوحدة للأشياء المؤلمة لاختبار الوحدة.
الهدف ليس تغطية الكود بنسبة 100% ولا تغطية الكود بنسبة 80%.إن كون اختبار الوحدة سهل الكتابة لا يعني أنه يجب عليك كتابته، كما أن صعوبة كتابة اختبارات الوحدة لا يعني أنه يجب عليك تجنب بذل هذا الجهد.
الهدف من أي اختبار هو اكتشاف المشكلات المرئية للمستخدم بأفضل طريقة ميسورة التكلفة.
هل التكلفة الإجمالية لتأليف وصيانة وتشخيص المشكلات التي يشير إليها الاختبار (بما في ذلك الإيجابيات الكاذبة) تستحق المشكلات التي يكتشفها اختبار معين؟
إذا كانت المشكلة التي اكتشفها الاختبار "باهظة الثمن"، فيمكنك بذل جهد لمعرفة كيفية اختبارها والحفاظ على هذا الاختبار.إذا كانت المشكلة التي اكتشفها الاختبار تافهة، فمن الأفضل أن تكون كتابة الاختبار (والمحافظة عليه!) (حتى في حالة وجود تغييرات في التعليمات البرمجية) تافهة.
الهدف الأساسي لاختبار الوحدة هو حماية المطورين من أخطاء التنفيذ.وهذا وحده ينبغي أن يشير إلى أن الكثير من الجهد سيكون مضيعة للوقت.بعد نقطة معينة، توجد استراتيجيات أفضل للحصول على التنفيذ الصحيح.أيضًا بعد نقطة معينة، تكون المشكلات المرئية للمستخدم ناتجة عن تنفيذ الشيء الخاطئ بشكل صحيح والذي لا يمكن اكتشافه إلا عن طريق مستوى المستخدم أو اختبار التكامل.
ما الذي لن تختبره؟أي شيء لا يمكن كسره.
عندما يتعلق الأمر بتغطية التعليمات البرمجية، فأنت تريد أن تستهدف 100% من التعليمات البرمجية التي تكتبها بالفعل - وهذا يعني أنك لا تحتاج إلى اختبار تعليمات برمجية لمكتبة تابعة لجهة خارجية، أو تعليمات برمجية لنظام التشغيل حيث سيتم تسليم هذا التعليمات البرمجية إليك بعد اختبارها.ما لم يكن الأمر كذلك.وفي هذه الحالة قد ترغب في اختباره.أو إذا كانت هناك أخطاء معروفة، ففي هذه الحالة قد ترغب في اختبار وجود الأخطاء، حتى تحصل على إشعار عند إصلاحها.
أعتقد أن اختبار الوحدة لواجهة المستخدم الرسومية أمر صعب أيضًا، وإن لم يكن مستحيلًا.
الوصول إلى البيانات ممكن لأنه يمكنك إعداد قاعدة بيانات اختبارية.
بشكل عام، الأشياء "غير القابلة للاختبار" هي بروتوكول نقل الملفات والبريد الإلكتروني وما إلى ذلك.ومع ذلك، فهي بشكل عام فئات إطارية يمكنك الاعتماد عليها وبالتالي لا تحتاج إلى اختبار ما إذا كنت تخفيها خلف تجريد.
كما أن تغطية الكود بنسبة 100% ليست كافية في حد ذاتها.
@ جاري شوتلر
أنا في الواقع أقوم بوحدة اختبار البريد الإلكتروني باستخدام خادم SMTP مزيف (Wiser).تأكد من صحة رمز التطبيق:
http://maas-frensch.com/peter/2007/08/29/unittesting-e-mail-sending-using-spring/
ربما يمكن القيام بشيء كهذا للخوادم الأخرى.وإلا فيجب أن تكون قادرًا على الاستهزاء بواجهة برمجة التطبيقات (API)...
بالمناسبة:التغطية 100% هي البداية فقط...يعني فقط أن جميع التعليمات البرمجية قد تم تنفيذها بالفعل مرة واحدة....لا شيء عن حالات الحافة وما إلى ذلك.
معظم الاختبارات التي تحتاج إلى إعدادات ضخمة ومكلفة (من حيث تكلفة الموارد أو وقت الحساب) هي اختبارات تكامل.يجب أن تختبر اختبارات الوحدة (نظريًا) وحدات صغيرة فقط من الكود.وظائف فردية.
على سبيل المثال، إذا كنت تختبر وظيفة البريد الإلكتروني، فمن المنطقي إنشاء بريد وهمي.الغرض من هذا النموذج هو التأكد من أن الكود الخاص بك يتصل بمرسل البريد بشكل صحيح.لمعرفة ما إذا كان تطبيقك يرسل بريدًا فعليًا يعد اختبارًا للتكامل.
من المفيد جدًا التمييز بين اختبارات الوحدة واختبارات التكامل.يجب أن تعمل اختبارات الوحدة بسرعة كبيرة.يجب أن يكون من الممكن بسهولة إجراء جميع اختبارات الوحدة الخاصة بك قبل التحقق من التعليمات البرمجية الخاصة بك.
ومع ذلك، إذا كانت مجموعة الاختبار الخاصة بك تتكون من العديد من اختبارات التكامل (التي تقوم بإعداد قواعد البيانات وتدميرها وما شابه ذلك)، فيمكن أن يتجاوز تشغيل الاختبار نصف ساعة بسهولة.في هذه الحالة، من المحتمل جدًا ألا يقوم المطور بإجراء جميع اختبارات الوحدة قبل تسجيل الوصول.
لذلك للإجابة على سؤالك:قم بإجراء أشياء اختبار الوحدة الصافية، والتي يتم تنفيذها بشكل أفضل كاختبار تكامل (وأيضًا لا تختبر getter/setter - فهي مضيعة للوقت ؛-)).
في اختبار الوحدة، يجب ألا تختبر أي شيء لا ينتمي إلى وحدتك؛وحدات الاختبار في سياقها مسألة مختلفة.هذه هي الإجابة البسيطة.
القاعدة الأساسية التي أستخدمها هي أنه يجب عليك اختبار الوحدة لأي شيء يمس حدود وحدتك (عادةً الفصل الدراسي، أو أي شيء آخر قد تكون وحدتك)، والاستهزاء بالباقي.ليست هناك حاجة لاختبار النتائج التي ترجعها بعض استعلامات قاعدة البيانات، يكفي اختبار أن وحدتك تبث الاستعلام الصحيح.
هذا لا يعني أنه لا ينبغي عليك حذف الأشياء التي يصعب اختبارها؛حتى معالجة الاستثناءات ومشكلات التزامن يمكن اختبارها جيدًا باستخدام الأدوات المناسبة.
"ما الذي لا يجب اختباره عندما يتعلق الأمر باختبار الوحدة؟" * الفاصوليا مع فقط getters والمقاطع.منطق:عادةً ما يكون مضيعة للوقت، وكان من الأفضل قضاءه في اختبار شيء آخر.
أي شيء غير حتمي تمامًا هو أمر محظور لاختبار الوحدة.تريد أن تنجح اختبارات الوحدة الخاصة بك أو تفشل دائمًا بنفس الشروط الأولية - إذا كان من الممكن أن تؤثر غرابة مثل الخيوط، أو إنشاء البيانات العشوائية، أو الوقت/التواريخ، أو الخدمات الخارجية على ذلك، فلا ينبغي عليك تغطيتها في اختبارات الوحدة الخاصة بك .الوقت/التواريخ هي حالة سيئة بشكل خاص.يمكنك عادةً تصميم التعليمات البرمجية للحصول على تاريخ للعمل به (عن طريق التعليمات البرمجية والاختبارات) بدلاً من الاعتماد على الوظيفة في التاريخ والوقت الحاليين.
ومع ذلك، لا ينبغي أن تكون اختبارات الوحدة هي المستوى الوحيد للاختبار في تطبيقك.غالبًا ما يكون تحقيق تغطية اختبار الوحدة بنسبة 100% مضيعة للوقت، وسرعان ما يلبي العوائد المتناقصة.
والأفضل بكثير هو أن يكون لديك مجموعة من الاختبارات الوظيفية ذات المستوى الأعلى، وحتى اختبارات التكامل للتأكد من أن النظام يعمل بشكل صحيح "بمجرد ضم كل شيء" - التي تختبرها الوحدة بالتعريف لا امتحان.
أي شيء يحتاج إلى إعداد كبير جدًا ومعقد.بالطبع يمكنك اختبار بروتوكول نقل الملفات (العميل)، ولكن بعد ذلك تحتاج إلى إعداد خادم بروتوكول نقل الملفات.لاختبار الوحدة، تحتاج إلى إعداد اختبار قابل للتكرار.إذا لم تتمكن من توفيره، لا يمكنك اختباره.
يمكنك اختبارها، لكنها لن تكون اختبارات وحدة.اختبار الوحدة هو شيء لا يتجاوز الحدود، مثل عبور السلك، أو ضرب قاعدة البيانات، أو التشغيل/التفاعل مع طرف ثالث، أو لمس قاعدة تعليمات برمجية قديمة/غير مختبرة، وما إلى ذلك.
أي شيء أبعد من هذا هو اختبار التكامل.
الإجابة الواضحة للسؤال الموجود في العنوان هي أنه لا ينبغي لك اختبار الوحدة الداخلية لواجهة برمجة التطبيقات (API) الخاصة بك، ولا يجب أن تعتمد على سلوك شخص آخر، ولا يجب عليك اختبار أي شيء لست مسؤولاً عنه.
يجب أن يكون الباقي كافيًا فقط لتتمكن من كتابة التعليمات البرمجية الخاصة بك بداخله، وليس أكثر ولا أقل.
بالتأكيد تغطية 100% أمر جيد هدف عند العمل على مشروع كبير، ولكن بالنسبة لمعظم المشاريع، فإن إصلاح خطأ واحد أو اثنين قبل النشر لا يستحق بالضرورة الوقت لإنشاء اختبارات شاملة للوحدة.
غالبًا ما يكون الاختبار الشامل لأشياء مثل تقديم النماذج، والوصول إلى قاعدة البيانات، والوصول إلى FTP، وما إلى ذلك على مستوى مفصل للغاية مجرد مضيعة للوقت؛ما لم يكن البرنامج الذي تتم كتابته يحتاج إلى مستوى عالٍ جدًا من الموثوقية (99.999٪ من الأشياء)، فإن اختبار الوحدة أكثر من اللازم يمكن أن يكون مبالغة وإهدارًا في الوقت الفعلي.
أنا لا أتفق مع رد Quamrana فيما يتعلق بعدم اختبار كود الطرف الثالث.هذا هو الاستخدام الأمثل لاختبار الوحدة.ماذا لو تم تقديم الأخطاء في الإصدار الجديد للمكتبة؟من الناحية المثالية، عند إصدار إصدار جديد من مكتبة جهة خارجية، يمكنك تشغيل اختبارات الوحدة التي تمثل السلوك المتوقع لهذه المكتبة للتحقق من أنها لا تزال تعمل كما هو متوقع.
يعد التكوين عنصرًا آخر يصعب اختباره جيدًا في اختبارات الوحدة.يجب إجراء اختبارات التكامل والاختبارات الأخرى مقابل التكوين.وهذا يقلل من تكرار الاختبار ويوفر الكثير من الوقت.غالبًا ما تكون محاولة تكوين اختبار الوحدة أمرًا تافهًا.
يجب اختبار FTP وSMTP وI/O بشكل عام باستخدام واجهة.يجب أن يتم تنفيذ الواجهة بواسطة محول (للرمز الحقيقي) ونموذج لاختبار الوحدة.
لا ينبغي أن يستخدم أي اختبار للوحدة المورد الخارجي الحقيقي (خادم FTP وما إلى ذلك)
إذا أصبح الكود الخاص بإعداد الحالة المطلوبة لاختبار الوحدة أكثر تعقيدًا بكثير من الكود المطلوب اختباره، فإنني أميل إلى رسم الخط وإيجاد طريقة أخرى لاختبار الوظيفة.في تلك المرحلة عليك أن تسأل كيف تعرف أن اختبار الوحدة صحيح!
يمكنك اختبار بروتوكول نقل الملفات والبريد الإلكتروني وما إلى ذلك باستخدام محاكاة الخادم.إنه أمر صعب ولكنه ممكن.
لا يمكن اختبار بعض الأخطاء في التعامل معها.يوجد في كل كود معالجة أخطاء لا يمكن أن تحدث أبدًا.على سبيل المثال، في Java، يجب أن يكون هناك العديد من الاستثناءات لأنها جزء من الواجهة.لكن المثيل المستخدم لن يرميه أبدًا.أو الحالة الافتراضية للمحول في حالة وجود كتلة حالة لجميع الحالات المحتملة.
بالطبع يمكن إزالة بعض الأخطاء غير المطلوبة في المعالجة.ولكن هل هناك خطأ في الترميز في المستقبل فهذا أمر سيء.
السبب الرئيسي لاختبار الكود في المقام الأول هو التحقق من صحة تصميم الكود الخاص بك.من الممكن الحصول على تغطية للتعليمات البرمجية بنسبة 100%، ولكن ليس بدون استخدام كائنات وهمية أو شكل من أشكال العزل أو حقن التبعية.
تذكر أن اختبارات الوحدة ليست مخصصة للمستخدمين، ولكنها مخصصة للمطورين ولإنشاء أنظمة لاستخدامها للتحقق من صحة النظام قبل إصداره.ولتحقيق هذه الغاية، يجب أن تعمل اختبارات الوحدة بسرعة كبيرة وأن يكون بها أقل قدر ممكن من احتكاك التكوين والتبعية.حاول أن تفعل قدر ما تستطيع في الذاكرة، وتجنب استخدام اتصالات الشبكة من الاختبارات.
