ما معنى ذلك؟
عند الانتقال من الإصدار 2 إلى إصدار Manifest V3، يتم إجراء تغيير جوهري عليه. في الإصدار 2 من Manifest V2، كانت الإضافات متوفّرة في صفحة خلفية. تمكنت صفحات الخلفية من إدارة عملية التواصل بين الإضافات وصفحات الويب. يستخدم إصدار Manifest V3 مشغّلي الخدمات بدلاً من ذلك.
في هذه المشاركة، نتناول مشكلة اختبار موظفي خدمات الإضافات. ونحن نلقي نظرة على وجه الخصوص على كيفية التأكّد من أنّ منتجنا يعمل بشكل صحيح في حال تعليق مشغّل الخدمات.
من نحن؟
eyeo هي شركة متخصّصة في توفير تبادل متوازن ومستدام للقيمة على الإنترنت للمستخدمين والمتصفّحات والمعلنين والناشرين. هناك أكثر من 300 مليون مستخدم على مستوى العالم لفلترة الإعلانات يمكنهم عرض "الإعلانات المقبولة"، وهي معيار إعلاني مشتق بشكل مستقل ويحدِّد ما إذا كان الإعلان مقبولاً وغير تطفلي أم لا.
يوفّر فريق Extension Engine تقنية فلترة الإعلانات التي تعمل على تشغيل بعض إضافات المتصفحات الأكثر شيوعًا لحظر الإعلانات في السوق، مثل AdBlock وAdblock Plus مع أكثر من 110 مليون مستخدم حول العالم. بالإضافة إلى ذلك، نقدّم هذه التكنولوجيا على أنّها مكتبة مفتوحة المصدر، ما يجعلها متاحة للإضافات الأخرى في المتصفِّح التي تعمل على فلترة الإعلانات.
ما المقصود بعامل الخدمات؟
عامل خدمات الإضافات هم معالِج الأحداث المركزي لإضافة المتصفّح. تعمل هذه الإعلانات بشكل مستقل في الخلفية. لا بأس في ذلك بشكل عام. يمكننا تنفيذ معظم الإجراءات التي نحتاج إلى تنفيذها على صفحة الخلفية في مشغّل الخدمات الجديد. ولكن هناك بعض التغييرات مقارنةً بصفحات الخلفية:
- ويتم إنهاء مشغّلي الخدمات في حال عدم استخدامهم. وهذا يتطلب منا مواصلة حالات التطبيق بدلاً من الاعتماد على المتغيرات العامة. وهذا يعني أن أي نقاط دخول إلى نظامنا يجب أن تكون جاهزة للاتصال بها قبل تهيئة النظام.
- يجب إرفاق أدوات معالجة الأحداث قبل انتظار أي عمليات استدعاء غير متزامنة. سيظل بإمكان موظفي الخدمات المحظورين تلقّي الأحداث التي اشتركوا فيها. إذا لم يتم تسجيل أداة معالجة الحدث في الحلقة الأولى من حلقة الحدث، لن يستقبل الحدث إذا أدّى هذا الحدث إلى تنشيط عامل الخدمة.
- يمكن لإنهاء وضع عدم النشاط أن تعيق الموقّتات قبل اكتمالها.
متى يتم تعليق حسابات عمال الخدمة؟
بالنسبة إلى الإصدار 119 من Chrome، ما واجهناه هو أنّ موظفي الخدمة معلّقون:
- بعد عدم تلقّي الأحداث أو استدعاء واجهات برمجة تطبيقات الإضافات لمدة 30 ثانية
- مطلقًا إذا كانت أدوات المطوّرين مفتوحة أو كنت تستخدم مكتبة اختبار مستندة إلى ChromeDriver (الاطّلاع على طلب الميزة)
- إذا نقرت على إيقاف في chrome://servicework-internals.
لمزيد من المعلومات، يُرجى الرجوع إلى دورة حياة موظفي الخدمات.
لماذا يشكّل اختبار هذه المشكلة مشكلة؟
من الناحية المثالية، كان من المفيد الحصول على إرشادات رسمية حول "كيفية اختبار موظفي الخدمة بطريقة فعالة" أو أمثلة على اختبارات العمل. خلال مغامراتنا مع العاملين في مجال خدمة الاختبار، واجهنا بعض التحديات:
- وقد ذكرنا ذلك في إضافة الاختبار. عند توقُّف مشغّل الخدمات، لن يتم حفظ حالته والأحداث المسجَّلة. كيف سنواصل البيانات في تدفق الاختبار؟
- إذا كان من الممكن تعليق حسابات موظفي الخدمة في أي وقت، سنحتاج إلى اختبار عمل جميع الميزات في حال انقطاعها.
- وحتى إذا استخدمنا آلية في اختباراتنا تؤدي إلى تعليق مشغّلي الخدمة عشوائيًا، لا توجد واجهة برمجة تطبيقات في المتصفح لتعليقها بسهولة. لقد طلبنا من فريق W3C إضافة هذه الميزة، ولكن ما زالت هذه المحادثة مستمرة.
تعليق عامل خدمة الاختبار
لقد جربنا عدة طرق لبدء تعليق مشغّل الخدمات أثناء الاختبارات:
| الطريقة | المشاكل المتعلّقة بالأسلوب |
| الانتظار لفترة زمنية عشوائية (على سبيل المثال، 30 ثانية) | وهذا يجعل الاختبار بطيئًا وغير موثوق به، خاصةً عند إجراء اختبارات متعددة. ولا تعمل هذه الميزة عند استخدام WebDriver، لأنّها تستخدم واجهة برمجة تطبيقات أدوات مطوّري البرامج في Chrome، ولا يتم تعليق عامل الخدمة عندما تكون أدوات مطوّري البرامج مفتوحة. حتى إذا تمكّنا من تجاوز هذا الإجراء، لا يزال علينا التحقّق مما إذا كان مشغّل الخدمات قد تم تعليقه وليس لدينا طريقة لإجراء ذلك. |
| تشغيل حلقة لانهائية في مشغّل الخدمات | وفقًا للمواصفات، قد يؤدي ذلك إلى الإنهاء استنادًا إلى طريقة تنفيذ المتصفّح لهذه الوظيفة. لا ينهي Chrome مشغّل الخدمات في هذه الحالة، لذا لا يمكننا اختبار السيناريو عند تعليق عامل الخدمة. |
| توفُّر رسالة في مشغّل الخدمات للتحقّق مما إذا كان قد تم تعليقه | وفي حال إرسال رسالة، يتم تنشيط عامل الخدمة. يمكن استخدام هذه الطريقة للتحقّق مما إذا كان عامل الخدمة نائمًا، ولكنه يعطّل نتائج الاختبارات التي تحتاج إلى إجراء عمليات تحقّق فورًا بعد تعليق مشغّل الخدمة. |
| إيقاف عملية مشغِّل الخدمات باستخدام chrome.processes.terminate() | يشارك مشغّل الخدمات للإضافة عملية مع أجزاء أخرى من الإضافة، لذا فإن إنهاء هذه العملية باستخدام chrome.process.terminate() أو واجهة المستخدم الرسومية لمدير العمليات في Chrome لا يؤدي إلى إنهاء مشغّل الخدمة فحسب، بل يؤدي أيضًا إلى إنهاء أي صفحات إضافات. |
انتهى بنا الأمر إلى اختبار يتحقّق من استجابة الرمز البرمجي لعامل الخدمة الذي يتم تعليقه، وذلك من خلال فتح Selenium WebDriver على chrome://serviceWORK-internals/ والنقر على زر "إيقاف" لعامل الخدمة.
هذا هو الخيار الأفضل حتى الآن، لكنه ليس مثاليًا لأن اختبارات Mocha (التي يتم إجراؤها على صفحة إضافة) لا يمكنها إجراء ذلك بنفسها، لذلك تحتاج إلى الاتصال ببرنامج عُقد WebDriver مرة أخرى. ويعني ذلك أنّه لا يمكن إجراء هذه الاختبارات باستخدام الإضافة فقط، بل يجب تشغيلها باستخدام Selenium WebDriver.
في ما يلي رسم توضيحي يوضِّح كيفية تواصلنا مع واجهة برمجة تطبيقات المتصفِّح من خلال تدفقات مختلفة، وتأثير إضافة آلية "تعليق العاملين في الخدمة" فيها.
في تدفق جديد يعلّق مشغّلي الخدمات (باللون الأزرق)، أضفنا Selenium WebDriver إلى "النقر" للتعليق عبر واجهة المستخدم، ما يؤدي إلى تشغيل إجراء في واجهة برمجة تطبيقات المتصفح.
وتجدر الإشارة إلى أنّ هناك خطأً في Chrome تسبّب في عدم تمكّن عامل الخدمة من بدء العمل مرة أخرى نتيجة إجراء هذا الخطأ باستخدام Selenium WebDriver. تم إصلاح ذلك في الإصدار 116 من Chrome، ويتوفّر حل بديل: يؤدي ضبط Chrome على فتح "أدوات مطوري البرامج" تلقائيًا في كل علامة تبويب إلى تشغيل مشغّل الخدمة بشكل صحيح.
نحن نستخدم هذه الطريقة عند الاختبار على الرغم من أنّها ليست مثالية، لأنّ النقر على الزر قد لا يكون واجهة برمجة تطبيقات مستقرة، ويبدو أنّ فتح "أدوات مطوري البرامج" (للمتصفّحات القديمة) له تكلفة أداء.
كيف نغطي الوظائف بالكامل؟ اختبارات الزغب
بعد حصولنا على آلية لاختبار التعليق، كان علينا أن نقرر كيفية توصيله بمجموعات اختبار التشغيل الآلي. لقد أجرينا اختباراتنا العادية في بيئة يتم فيها تعليق مشغّل الخدمة قبل كل تفاعل مع صفحة الخلفية، وذلك من خلال WebDriver عند النقر على إيقاف في صفحة chrome://serviceWORK-internals/ .
نحن نُجري معظم الاختبارات وليس جميعها لأنّ آلية التعليق لا تكون مستقرة بالكامل، وأحيانًا تؤدي إلى تقطُّعها. يستغرق أيضًا تشغيل جميع مجموعات الاختبار في وضع الزغب الكثير من الوقت. لذا، بدلاً من تناول جميع الحالات "المشابهة"، اخترنا المسارات الأكثر أهمية للاختبار في وضع ضبابي. من الجدير بالذكر أنّ إجراء اختبارات وظيفية في وضع "الضبابية" يعني أنه كان علينا زيادة مهلات الاختبارات لأن تعليق العاملين في الخدمة وإعادة تشغيلهم يستغرق وقتًا إضافيًا.
هذه الاختبارات مهمة باعتبارها محاولة أولى عامة تُلقي الضوء على العديد من الأماكن التي يفشل فيها الرمز، ولكنها قد لا تكشف بالضرورة عن جميع الطرق الخبيثة التي قد يؤدي بها تعليق عامل الخدمة إلى حدوث أعطال في الأمور.
داخليًا، نطلق على هذه الأنواع من الاختبارات اسم "اختبارات نبضات Google". عادةً ما يتم إجراء اختبار الزغب عند طرح إدخال غير صالح في برنامجك والتأكّد من استجابته بشكل معقول، أو على الأقل عدم تعطُّله. في هذه الحالة، يشير "الإدخال غير الصالح" إلى تعليق مشغّل الخدمات في أي وقت، و "السلوك المعقول" الذي نتوقعه هو استمرار عمل وظيفة فلترة الإعلانات على النحو السابق. هذا الإدخال ليس غير صالح لأنّ هذا السلوك متوقّع في الإصدار 3 من البيان، ولكنّه سيكون غير صالح في الإصدار 2، ما يعني أنّ المصطلحات تبدو معقولة.
ملخّص
يشكّل مشغّلو الخدمات أحد أهم التغييرات في الإصدار الثالث من البيان (إلى جانب قواعد declarativeNetRequest). قد يتطلب نقل البيانات إلى إصدار Manifest V3 إجراء العديد من التغييرات على الرموز البرمجية في إضافات المتصفّح وطرق جديدة للاختبار. وتتطلّب هذه السياسة أيضًا من مطوّري الإضافات التي لها حالة دائمة تحضير الإضافات للتعامل بشكل سلس مع التعليق غير المتوقَّع لمشغّل الخدمات.
لا تتوفّر واجهة برمجة تطبيقات للتعامل مع التعليق بطريقة سهلة تناسب حالة الاستخدام لدينا. وبما أنّنا أردنا اختبار قوة قاعدة رموز الإضافة مقارنةً بآليات التعليق في مرحلة مبكرة، كان علينا العمل على حل هذه المشكلة. ويمكن لمطوِّري الإضافات الآخرين الذين يواجهون تحديات مماثلة استخدام هذا الحل البديل، علمًا أنّ هذا الحل البديل يستغرق وقتًا طويلاً في مرحلة التطوير والصيانة، إلا أنه يستحق العناء حتى يتسنّى لنا التأكّد من إمكانية تشغيل الإضافات بنجاح في بيئة يتم فيها تعليق العاملين بشكل منتظم.
على الرغم من توفُّر دعم أساسي لاختبار تعليق حسابات مشغِّلي الخدمات حاليًا، نودّ بشدة أن نشهد دعمًا أفضل للنظام الأساسي لمشغّلي خدمات الاختبار من داخل الإضافات، وذلك لأنّ ذلك قد يقلّل بشكل كبير من أوقات تنفيذ الاختبار وجهود الصيانة.