البرمجة وتطوير البرمجيات

دليل Microsoft لاختبار تطبيقات UWP وWinUI 3 باستخدام MSTest

تشرح Microsoft كيفية اختبار واجهات تطبيقات UWP وWinUI 3 باستخدام MSTest وMicrosoft.Testing.Platform عبر نماذج التشغيل المعبأة وغير المعبأة وAppContainer. ويركز الدليل على إعداد المضيف، تمرير وسيط التشغيل، دعم مُرحّل واجهة المستخدم، والتحقق من بيئة CI الفعلية.

05 أكتوبر 2026
4 دقائق قراءة
2 قراءة
certi.news Editorial Team
دليل Microsoft لاختبار تطبيقات UWP وWinUI 3 باستخدام MSTest

قدمت Microsoft دليلاً عملياً لاختبار تطبيقات UWP وWinUI 3 بوساطة MSTest وMicrosoft.Testing.Platform، مع توحيد دورة حياة الاختبارات عبر نماذج تشغيل مختلفة تشمل التطبيقات المعبأة بصيغة MSIX، والتطبيقات غير المعبأة، والتطبيقات التي تعمل داخل AppContainer. المادة كتبها Amaury Levé، مهندس برمجيات رئيسي، وتركز على التفاصيل التي تحدد طريقة تشغيل مضيف الاختبار أكثر من تركيزها على كتابة اختبارات الواجهة نفسها.

اختيار نموذج التشغيل

تفرق Microsoft بين التغليف ومستوى الثقة. فالتغليف يضيف هوية MSIX ووسيلة تنشيط AUMID، بينما يحدد مستوى الثقة ما إذا كانت العملية تعمل بصلاحيات كاملة أو داخل AppContainer. وتوصي المادة بالبدء بتطبيق WinUI 3 غير معبأ عندما لا تكون هوية الحزمة أو عقود التنشيط المعبأة أو مطابقة سلوك التطبيق المثبت مطلوبة. أما UWP فيبقى مرتبطاً بطبيعته بالتغليف وبيئة AppContainer.

في التطبيقات غير المعبأة يستخدم Microsoft.Testing.Platform مسار تشغيل مباشر من apphost، بينما تحتاج التطبيقات المعبأة إلى تسجيل تخطيط الحزمة والتنشيط عبر AUMID. أما تطبيقات WinUI 3 المهيأة للعمل داخل AppContainer فتحتاج كذلك إلى تفويض دقيق للوصول إلى قنوات الاتصال الخاصة بوحدة التحكم، والإلغاء، وملفات TRX، وHangDump، وإعادة المحاولة؛ وتحذر Microsoft من منح صلاحية ALL APPLICATION PACKAGES بدلاً من ذلك.

إعداد MSTest وMicrosoft.Testing.Platform

توصي Microsoft بتثبيت الإصدار MSTest.Sdk 4.5 واختيار Microsoft.Testing.Platform في ملف global.json، حتى يستخدم أمر dotnet test منصة الاختبار الأصلية في .NET 10 بدلاً من VSTest. ويتضمن MSTest.Sdk 4.5 منصة MTP 2.5، ووحدة التحكم الجانبية الخاصة بنماذج التطبيقات، وأصول UWP اللازمة، ومشغّل التطبيقات المعبأة.

في UWP الحديث يتطلب الإعداد استخدام UseUwp وPublishAot مع إطار استهداف Windows مناسب. ويجب على التطبيق تمرير وسيطات التنشيط إلى المساعد المُولّد MicrosoftTestingPlatformApplication.RunAsync من داخل OnLaunched، باستخدام PackagedAppExtensions.GetTestApplicationArguments. أما مشاريع UWP التقليدية فتحتفظ ببنيتها الحالية وتستورد MSTest.Sdk إلى جانب MSBuild.Sdk.Extras، ثم تُشغّل الاختبارات من Developer PowerShell عبر هدف InvokeTestingPlatform.

مضيف WinUI 3 ومُرحّل الواجهة

تقترح المادة بناء تطبيق اختبار WinUI 3 مستضاف ذاتياً، بحيث ينشئ التطبيق نافذته ويمتلك نقطة الدخول ثم يشغّل MSTest داخل العملية نفسها. بعد تفعيل النافذة، ينشر التطبيق كائن DispatcherQueue إلى UITestMethodAttribute.DispatcherQueue، ثم يستدعي RunAsync. ويجب تعيين Environment.ExitCode إلى نتيجة تشغيل الاختبارات، لأن نقطة الدخول التي ينشئها WinUI تعيد قيمة void، وقد يؤدي تجاهل ذلك إلى ظهور تشغيل فاشل على أنه ناجح أمام نظام البناء أو CI.

توضح العينة أن UITestMethod يمرر الاختبار الكامل، بما في ذلك TestInitialize وTestCleanup، إلى مُرحّل WinUI. أما STATestMethod فيوفر خيط STA لكنه لا ينشئ مُرحّل WinUI بحد ذاته، ولذلك لا يكفي وحده لاختبارات الواجهة التي تعتمد على DispatcherQueue.

ما الذي يتغير عملياً؟

القيمة الأساسية في هذا النهج هي إمكانية إبقاء MSTest ودورة حياة الاختبارات نفسها عند الانتقال بين UWP وWinUI 3 أو بين التشغيل المعبأ وغير المعبأ، مع تغيير إعدادات النشر ومسار الإطلاق فقط. في WinUI 3 غير المعبأ تُضبط WindowsPackageType إلى None ويُعطّل MSIX tooling. أما التشغيل المعبأ فيحتفظ ببيان Package.appxmanifest وأصول الحزمة، ويتطلب TFM من Windows عند 10.0.19041.0 أو أحدث وسياسة تسمح بالتثبيت الجانبي مثل Developer Mode.

يمكن تشغيل النموذجين عبر dotnet run أو dotnet test --project في .NET 10، بينما تُشغّل اختبارات UWP وWinUI 3 داخل AppContainer عبر هدف MSBuild المخصص ومن Developer PowerShell غير مرفوع الصلاحيات. وتحذر Microsoft من استخدام dotnet exec مع التطبيق غير المعبأ، لأن إدخال dotnet.exe في مسار التشغيل قد يسبب مشكلات في تحميل موارد WinUI.

التحقق داخل CI

لا يكفي نجاح البناء للتأكد من صلاحية الاختبارات المعبأة. ينبغي فحص صورة وكيل CI الفعلية، وسياق المستخدم الذي يسجل الحزمة، وسياسة Developer Mode أو التثبيت الجانبي، والأطر التي تعلنها الحزمة. وقد يخفي جهاز المطور المثبت عليه مسبقاً Windows App SDK أو حزم UWP فجوة لا تظهر إلا على وكيل نظيف. كما تحتاج التطبيقات المعتمدة على إطار Windows App SDK إلى الإصدار المطابق من وقت التشغيل، ما لم تُبنَ بصيغة self-contained، وحتى في هذه الحالة يجب اختبار نموذج الحزمة نفسه الذي سيُستخدم في CI.

مصدر الخبر
كيف أعددنا هذا الخبر؟

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

c
كاتب المقال

certi.news Editorial Team

certi.news Editorial Team

The certi.news editorial team monitors technical sources and reconstructs news, verifying facts and context prior to publication.

من نفس التصنيف

مقالات قد تهمك

عرض كل الأخبار