سؤال

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

هل سيكون هذا أسلوبًا قابلاً للتطبيق لاختبار تطبيق WPF؟هل هناك طريقة أفضل؟هل هناك أي مسكتات يجب الحذر منها؟

هل كانت مفيدة؟

المحلول

أما بالنسبة للاختبار نفسه، فمن الأفضل أن تستخدمه أتمتة واجهة المستخدم نطاق.أو إذا كنت تريد طريقة أكثر سلاسة ومستقلة عن wpf/winforms/win32/swt لاستخدام إطار العمل، فيمكنك التنزيل أبيض من Codeplex (شريطة أن تكون في وضع يسمح لك باستخدام كود مفتوح المصدر في بيئتك).

بالنسبة للمسكتك؛إذا كنت تحاول اختبار وجهات نظرك، فمن المحتمل أن تواجه بعض مشكلات الترابط.على سبيل المثال، إذا كنت تقوم بتشغيل NUnit، فسيتم تشغيل جهاز الاختبار الافتراضي في MTA (شقة متعددة الخيوط)، بينما يحتاج WPF إلى التشغيل كـ STA (شقة ذات خيوط واحدة). مايك اثنان يتمتع بسهولة البدء في اختبار الوحدة WPF، ولكن دون النظر إلى مشكلة الترابط.لدى جوش سميث بعض الأفكار حول مشكلة الترابط هذا المشنور, "، ويشير إليه أيضًا هذا المقال بواسطة كريس هيدجيت.يستخدم كريس نسخة معدلة من نسخة بيتر بروفوست CrossThreadTestRunner لحل مشكلات MTA/STA بطريقة أكثر ودية قليلاً.

نصائح أخرى

@مات ديفيد،

الرجاء قراءة الوثائق وإلقاء نظرة على نماذج التعليمات البرمجية لـ Microsoft مركبWPF (ويعرف أيضا باسم بريزم).إنه مشروع تم إنشاؤه خصيصًا لتعليم كيفية التعامل مع بنية MVP/MVC بطريقة قائمة على الاختبار.يحتوي نموذج التطبيق الخاص بهم على اختبارات الوحدة لمقدمي العروض/وحدات التحكم واختبارات القبول الرائعة جدًا لواجهة المستخدم (التي يستخدمونها الإطار الأبيض لمحاكاة إجراءات المستخدم)

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

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

ملاحظة:قد ترغب في المشاهدة هذا (Google Talk لماري بوبنديك على Lean)..وخاصة الجزء المتعلق بما يجب أتمتته في الاختبار

تحديث 2016: استخدم إطار عمل TestStack.White المجاني لأتمتة اختبار WPF UI

  • لقد تم التخلي عن مشروع وايت, ، بل خليفته TestStack.White متاح عبر حزمة NuGet.
  • يحتوي TestStack.White على طرق مساعدة لـ بدء تشغيل تطبيقات WPF, العثور على نافذة او شباك/عناصر التحكم للمستخدم, النقر على الأزرار/العناصر, ، محاكاة الماوس ولوحة المفاتيح أحداث, منتظر, ، إلخ..
  • يبدو المثال الذي سيقوم بتشغيل تطبيق WPF، والنقر فوق الزر، والتحقق من النتيجة كما يلي:

    using TestStack.White;
    using TestStack.White.UIItems;
    using TestStack.White.Factory;
    
    [TestMethod]
    public void TestDoSomething()
    {
        //Opens the app
        var app = Application.Launch("MyApp.exe");
    
        //Finds the main window (this and above line should be in [TestInitialize])
        var window = app.GetWindow("My App Window Title", InitializeOption.NoCache);
    
        //Finds the button (see other Get...() methods for options)
        var btnMyButton = window.Get<Button>("btnMyButtonWPFname");
    
        //Simulate clicking
        btnMyButton.Click();
    
        //Gets the result text box 
        //Note: TextBox/Button is in TestStack.White.UIItems namespace
        var txtMyTextBox = window.Get<TextBox>("txtMyTextBox");
    
        //Check for the result
        Assert.IsTrue(txtMyTextBox.Text == "my expected result");
    
        //Close the main window and the app (preferably in [TestCleanup])
        app.Close();
    }
    

المنشور (WPF المركب) تم تصميمه بشكل أساسي مع وضع "قابلية الاختبار" في الاعتبار.قم بذلك، إذا كنت تعتقد أنه يناسب نوع التطوير الخاص بك.

وهنا أيضا حلقة دوت نت روكس يمكنك الاستماع إليه، إذا كنت بحاجة إلى مزيد من المعلومات حول Prism صوتيًا.

للتعرف على الأساسيات، يمكنك أيضًا الاطلاع على بعض مقاطع الفيديو القصيرة على القناة 9 هنا و هنا.

يمكنك أيضًا التجربة جويا.يسمح لك باختبار وحدة WPF UserControls الفردية مباشرة.

ستعمل بشكل جيد وأسهل من نماذج الفوز.

تحقق من "دليل جودة تطبيق WPF"، فهو يحتوي على قدر كبير من المعلومات حول اختبار واجهة WPF.لا تنس أيضًا فئة AutomationPeer.

انظر بالتأكيد إلى موقع TestAutomationFX.com.يمكن للمرء أن يستثمر (حسنًا، لقد فعلت ذلك) الكثير من الوقت في محاولة التقاط/تسجيل الأحداث باستخدام White.(في بداية سعيي تجاهلت المنشور أو اثنين في أماكن أخرى يشيران إليه).

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

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

جرب Ranorex V2.0 لأتمتة WPF.مع RanoreXPath وRanorex، يمكن فصل رمز أتمتة اختبار مستودع RanoreX تمامًا عن معلومات التعريف.يوفر Ranorex أيضًا محرر التقاط/إعادة تشغيل يعتمد على كائنات RanoreXPath.

بدلاً من استخدام أدوات الاختبار الآلية، يمكنك إنشاء اختبارات وحدة حقيقية لواجهة المستخدم الرسومية الخاصة بك باستخدام com.icuTest.

أود أن أوصي بـ TestAutomationFX أيضًا للأتمتة البسيطة لاختبار واجهة المستخدم.يتيح لك TestAutomationFX العمل باستخدام أدوات netAdvantage لـ wpf أيضًا، والتي لا تعمل مع الأبيض وQTP.يتمتع TestAutomationFX بواجهة سهلة الاستخدام، فهو يتكامل مع الاستوديو المرئي ويحتوي على مسجل جيد لتسجيل أحداث المستخدم.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top