اختبار واجهة المستخدم والحدث

Question

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

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

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

يجب أن يكون هناك بعض التمهيديات والمستندات المبدئية هناك؟بعض التلميحات والنصائح؟

أنا أعمل بشكل عام في C# (2.0 و3.5) لكنني لست متأكدًا من أن هذا وثيق الصلة بالسؤال.

Answer 1

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

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

Answer 2

اقرا هذا إذا كنت تواجه صعوبة في اختبار واجهة المستخدم

قم باختبار عناصر واجهة المستخدم يدويًا حيث تكون فائدة التكلفة في أتمتتها ضئيلة.اختبر كل شيء تحت سطح واجهة المستخدم بلا رحمة.استخدم Humble Dialog أو MVC أو المتغيرات لإبقاء المنطق وواجهة المستخدم متميزين ومترابطين بشكل غير محكم.

Answer 3

يجب عليك فصل المنطق والعرض التقديمي.باستخدام أنماط MVP(Model-View-Presenter)/MVC (Model-View-Controller)، يمكنك اختبار المنطق الخاص بك دون الاعتماد على أحداث واجهة المستخدم.كما يمكنك استخدام الإطار الأبيض لمحاكاة إدخال المستخدم.أنصحك بشدة بزيارة موقع مايكروسوفت مركز مطور الأنماط والممارسات, ، قم بإلقاء نظرة خاصة على كتلة التطبيق المركبة والمنشور - حيث يمكنك الحصول على الكثير من المعلومات حول التصميم القائم على الاختبار.

Answer 4

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

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