وحدة اختبار تطبيقات MFC UI؟

Question

كيف يمكنك اختبار وحدة تطبيق MFC UI كبير؟

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

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

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

البيئة هي C++/C/FORTRAN، وMSVC 2005، وIntel FORTRAN 9.1، وWindows XP/Vista x86 & x64.

Answer 1

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

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

إنه في الواقع سهل جدًا:

افترض أن عنصر التحكم/النافذة/أي شيء يغير محتويات مربع القائمة عندما ينقر المستخدم على زر وتريد التأكد من أن مربع القائمة يحتوي على العناصر الصحيحة بعد النقر.

1. قم بإعادة البناء بحيث تكون هناك قائمة منفصلة تحتوي على العناصر التي سيتم عرضها في مربع القائمة.يتم تخزين العناصر في القائمة ولا يتم استخراجها من أي مكان تأتي منه بياناتك.الكود الذي يجعل قائمة مربعات القائمة يعرف الأشياء فقط عن القائمة الجديدة.
2. ثم تقوم بإنشاء كائن تحكم جديد والذي سيحتوي على الكود المنطقي.الطريقة التي تتعامل مع النقر على الزر تستدعي فقط mycontroller->ButtonWasClicked().لا يعرف عن مربع القائمة أو أي شيء آخر.
3. يقوم MyController::ButtonWasClicked() بتنفيذ ما يجب القيام به للمنطق المقصود، وإعداد قائمة العناصر وإخبار عنصر التحكم بالتحديث.لكي يعمل ذلك، تحتاج إلى فصل وحدة التحكم وعنصر التحكم عن طريق إنشاء واجهة (فئة افتراضية خالصة) لعنصر التحكم.وحدة التحكم تعرف كائنًا من هذا النوع فقط، وليس عنصر التحكم.

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

Answer 2

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

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

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

كان الطريق السهل هو إجابتي السابقة.هذا هو الطريق الصعب ولكن الصحيح للخروج.

Answer 3

أدرك أن هذا سؤال قديم، ولكن بالنسبة لأولئك منا الذين ما زالوا يعملون مع MFC، فإن Microsoft C++ Unit Testing Framework في VS2012 يعمل بشكل جيد.

الإجراء العام:

1. قم بتجميع مشروع MFC الخاص بك كمكتبة ثابتة
2. أضف مشروع اختبار الوحدة الأصلية الجديد إلى الحل الخاص بك.
3. في مشروع الاختبار، قم بإضافة مشروع MFC الخاص بك كمرجع.
4. في خصائص تكوين مشروع الاختبار، أضف أدلة التضمين لملفات الرأس الخاصة بك.
5. في الرابط، تضيف خيارات الإدخال MFC.lib;nafxcwd.lib;libcmtd.lib;
6. ضمن "تجاهل المكتبات الافتراضية المحددة" أضف nafxcwd.lib;libcmtd.lib;
7. ضمن عام، قم بإضافة موقع ملف lib الذي تم تصديره من MFC.

ال https://stackoverflow.com/questions/1146338/error-lnk2005-new-and-delete-already-define-in-libcmtd-libnew-obj يحتوي على وصف جيد لسبب حاجتك إلى nafxcwd.lib وlibcmtd.lib.

الشيء المهم الآخر الذي يجب التحقق منه في المشاريع القديمة.في خصائص التكوين العام، تأكد من أن كلا المشروعين يستخدمان نفس "مجموعة الأحرف".إذا كان MFC الخاص بك يستخدم مجموعة أحرف متعددة البايت، فستحتاج إلى اختبار MS للقيام بذلك أيضًا.

Answer 4

على الرغم من أنها ليست مثالية، فإن أفضل ما وجدته لهذا هو AutoIt http://www.autoitscript.com/autoit3

"AutoIt v3 هي لغة برمجة نصية مجانية تشبه BASIC مصممة لأتمتة واجهة المستخدم الرسومية لنظام التشغيل Windows والبرمجة النصية العامة.ويستخدم مزيجًا من ضغطات المفاتيح المحاكاة وحركة الماوس ومعالجة النوافذ/التحكم من أجل أتمتة المهام بطريقة غير ممكنة أو موثوقة مع اللغات الأخرى (على سبيل المثال.VBScript وSendKeys).كما أن AutoIt صغير جدًا ومكتفي بذاته وسيتم تشغيله على كافة إصدارات Windows الجاهزة دون الحاجة إلى "أوقات تشغيل" مزعجة!

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

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

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

Answer 5

على الرغم من أنه لا يمكنه التعامل مع جانب واجهة المستخدم، إلا أنني أقوم باختبار كود MFC باستخدام مكتبة Boost Test.هناك مقالة مشروع Code حول البدء:

تصميم كائنات قوية مع Boost

Answer 6

حسنًا، لدينا أحد تطبيقات MFC الضخمة هذه في مكان العمل.إنه ألم هائل للحفاظ عليه أو تمديده.إنها كرة ضخمة من الطين الآن ولكنها تتراكم في المللى. على أي حال

• نحن نستخدم الروبوت العقلاني لإجراء اختبارات الدخان وما شابه ذلك.

• النهج الآخر الذي حقق بعض النجاح هو إنشاء لغة صغيرة خاصة بالمنتج و اختبارات البرنامج النصي التي تستخدم VBScript وبعض عناصر التحكم تتعامل مع سحر التجسس.تحويل الإجراءات الشائعة إلى أوامر..على سبيل المثالسيكون OpenDatabase أمرًا يقوم بدوره بإدخال كتل البرامج النصية المطلوبة للنقر على القائمة الرئيسية > ملف > "فتح...".يمكنك بعد ذلك إنشاء أوراق Excel وهي عبارة عن سلسلة من هذه الأوامر.يمكن لهذه الأوامر أن تأخذ معلمات أيضًا.شيء مثل اختبار الـ FIT ..ولكن المزيد من العمل.بمجرد تحديد معظم الأوامر الشائعة وإعداد البرامج النصية.إنها تقوم باختيار البرامج النصية وتجميعها (التي تم وضع علامة عليها بواسطة CommandIDs) لكتابة اختبارات جديدة.يقوم عداء الاختبار بتوزيع أوراق Excel هذه، ويجمع كل كتل البرامج النصية الصغيرة في برنامج نصي اختباري ويقوم بتشغيله.

  1. قاعدة البيانات المفتوحة "C: ests\MyDB"
  2. الحوار المفتوح "إضافة نموذج"
  3. AddModel "M0001"، "MyModel"، 2.5، 100
  4. اضغط موافق
  5. حفظ قاعدة البيانات

هث

Answer 7

في الواقع، كنا نستخدم Rational Team Test، ثم Robot، ولكن في المناقشات الأخيرة مع Rational اكتشفنا أنه ليس لديهم أي خطط لدعم تطبيقات Native x64 التي تركز بشكل أكبر على .NET، لذلك قررنا تبديل أدوات ضمان الجودة الآلية.يعد هذا أمرًا رائعًا ولكن تكاليف الترخيص لا تسمح لنا بتمكينه لجميع المطورين.

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

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