مقدمة لأوامر الموبايل المخصصة والمحسنة في WebdriverIO

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

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

لماذا أوامر الموبايل المخصصة؟

1. تبسيط واجهات برمجة التطبيقات المعقدة

بعض أوامر Appium، مثل الإيماءات أو تفاعلات العناصر، تتضمن بناء جملة مطولة ومعقدة. على سبيل المثال، تنفيذ إجراء الضغط الطويل باستخدام واجهة برمجة تطبيقات Appium الأصلية يتطلب بناء سلسلة action يدويًا:

const element = $('~Contacts')

await browser
    .action( 'pointer', { parameters: { pointerType: 'touch' } })
    .move({ origin: element })
    .down()
    .pause(1500)
    .up()
    .perform()

مع أوامر WebdriverIO المخصصة، يمكن تنفيذ نفس الإجراء بسطر واحد واضح من الكود:

await $('~Contacts').longPress();

هذا يقلل بشكل كبير من الكود الزائد، مما يجعل نصوصك البرمجية أنظف وأسهل للفهم.

2. تجريد عبر المنصات

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

await $('~element').scrollIntoView();

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

3. زيادة الإنتاجية

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

4. الاتساق وقابلية الصيانة

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

لماذا تحسين بعض أوامر الموبايل؟

1. إضافة المرونة

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

// مثال: تخصيص فواصل إعادة المحاولة والمهل الزمنية لاكتشاف عرض الويب
await driver.getContexts({
  returnDetailedContexts: true,
  androidWebviewConnectionRetryTime: 1000, // إعادة المحاولة كل 1 ثانية
  androidWebviewConnectTimeout: 10000,    // انتهاء المهلة بعد 10 ثوان
});

تساعد هذه الخيارات على تكييف نصوص الأتمتة مع سلوك التطبيق الديناميكي دون كود إضافي.

2. تحسين قابلية الاستخدام

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

// مثال: أمر محسن لتبديل السياق حسب العنوان
await driver.switchContext({
  title: 'My Webview Title',
});

مقارنة بطرق Appium الافتراضية، تلغي الأوامر المحسنة الحاجة إلى خطوات إضافية مثل استرداد السياقات المتاحة يدويًا والتصفية من خلالها.

3. توحيد السلوك

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

// مثال: أمر تمرير موحد لكلا المنصتين
await $('~element').scrollIntoView();

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

4. زيادة الموثوقية

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

// مثال: تبديل عرض الويب المحسن مع منطق مطابقة قوي
await driver.switchContext({
  url: /.*my-app\/dashboard/,
  androidWebviewConnectionRetryTime: 500,
  androidWebviewConnectTimeout: 7000,
});

هذا يجعل تنفيذ الاختبار أكثر قابلية للتنبؤ وأقل عرضة للفشل الناجم عن العوامل البيئية.

5. تعزيز قدرات التصحيح

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

// مثال: استرداد بيانات وصفية تفصيلية للتصحيح
const contexts = await driver.getContexts({ returnDetailedContexts: true });
console.log(contexts);

تساعد هذه البيانات الوصفية في تحديد المشكلات وحلها بشكل أسرع، مما يحسن تجربة التصحيح بشكل عام.

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

---

التطبيقات الهجينة

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

فهم عروض الويب

عرض الويب هو مكون شبيه بالمتصفح مضمن في تطبيق أصلي:

• Android: تعتمد عروض الويب على Chrome/System Webview وقد تحتوي على صفحات متعددة (مشابهة لعلامات تبويب المتصفح). تتطلب عروض الويب هذه ChromeDriver لأتمتة التفاعلات. يمكن لـ Appium تحديد إصدار ChromeDriver المطلوب تلقائيًا بناءً على إصدار System WebView أو Chrome المثبت على الجهاز وتنزيله تلقائيًا إذا لم يكن متوفرًا بالفعل. يضمن هذا النهج التوافق السلس ويقلل من الإعداد اليدوي. راجع وثائق Appium UIAutomator2 للتعرف على كيفية تنزيل Appium لإصدار ChromeDriver الصحيح تلقائيًا.
• iOS: تعمل عروض الويب بواسطة Safari (WebKit) ويتم تحديدها بواسطة معرفات عامة مثل WEBVIEW_{id}.

تحديات التطبيقات الهجينة

1. تحديد عرض الويب الصحيح من بين خيارات متعددة.
2. استرداد بيانات وصفية إضافية مثل العنوان أو الرابط أو اسم الحزمة للحصول على سياق أفضل.
3. التعامل مع الاختلافات الخاصة بالمنصة بين Android و iOS.
4. التبديل إلى السياق الصحيح في تطبيق هجين بشكل موثوق.

الأوامر الرئيسية للتطبيقات الهجينة

1. getContext

يسترجع السياق الحالي للجلسة. بشكل افتراضي، يتصرف مثل طريقة getContext من Appium ولكن يمكنه توفير معلومات سياق مفصلة عند تمكين returnDetailedContext. لمزيد من المعلومات انظر getContext

2. getContexts

يعيد قائمة مفصلة بالسياقات المتاحة، مما يحسن من طريقة contexts من Appium. هذا يجعل من السهل تحديد عرض الويب الصحيح للتفاعل دون استدعاء أوامر إضافية لتحديد العنوان أو الرابط أو bundleId|packageName النشط. لمزيد من المعلومات انظر getContexts

3. switchContext

ينتقل إلى عرض ويب محدد بناءً على الاسم أو العنوان أو الرابط. يوفر مرونة إضافية، مثل استخدام التعبيرات العادية للمطابقة. لمزيد من المعلومات انظر switchContext

الميزات الرئيسية للتطبيقات الهجينة

1. بيانات وصفية مفصلة: استرجاع تفاصيل شاملة للتصحيح وتبديل السياق الموثوق.
2. الاتساق عبر المنصات: سلوك موحد لنظامي Android و iOS، مع معالجة سلسة للميزات الخاصة بالمنصة.
3. منطق إعادة المحاولة المخصص (Android): ضبط فواصل إعادة المحاولة والمهل الزمنية لاكتشاف عرض الويب.

ملاحظات وقيود

• يوفر Android بيانات وصفية إضافية، مثل packageName و webviewPageId، بينما يركز iOS على bundleId.
• منطق إعادة المحاولة قابل للتخصيص لنظام Android ولكنه غير قابل للتطبيق على iOS.
• هناك العديد من الحالات التي لا يمكن لـ iOS العثور على عرض الويب. يوفر Appium قدرات إضافية مختلفة لـ appium-xcuitest-driver للعثور على عرض الويب. إذا كنت تعتقد أنه لم يتم العثور على عرض الويب، يمكنك تجربة تعيين إحدى القدرات التالية:
  • appium:includeSafariInWebviews: إضافة سياقات ويب Safari إلى قائمة السياقات المتاحة أثناء اختبار تطبيق أصلي/عرض ويب. هذا مفيد إذا كان الاختبار يفتح Safari ويحتاج إلى التفاعل معه. القيمة الافتراضية هي false.
  • appium:webviewConnectRetries: الحد الأقصى لعدد إعادة المحاولات قبل التخلي عن اكتشاف صفحات عرض الويب. التأخير بين كل إعادة محاولة هو 500 مللي ثانية، والافتراضي هو 10 محاولات.
  • appium:webviewConnectTimeout: الحد الأقصى للوقت بالمللي ثانية للانتظار حتى يتم اكتشاف صفحة عرض ويب. الافتراضي هو 5000 مللي ثانية.

للحصول على أمثلة متقدمة وتفاصيل، راجع وثائق واجهة برمجة تطبيقات الموبايل لـ WebdriverIO.

---

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