Web Components و Shadow DOM: التحدي غير المرئي للاختبار البصري

النقاط الرئيسية

Shadow DOM يغلّف الأنماط وDOM، مما يجعل مناهج الاختبار البصري الكلاسيكية عمياء جزئياً
الأدوات التي تفحص DOM «العادي» لا ترى العناصر داخل Shadow DOM بدون تكيّف محدد
النهج الهيكلي، المبني على خصائص CSS المحسوبة، يعمل عبر Shadow DOM لأنه يقرأ النتيجة النهائية للمتصفح
الـ Slots وCSS custom properties ووراثة الأنماط تخلق تفاعلات معقدة لا يمكن التحقق منها إلا بتحليل العرض الفعلي

تُعرِّف MDN Web Components بأنها "مجموعة تقنيات تتيح إنشاء عناصر HTML مخصصة قابلة لإعادة الاستخدام تكون وظيفتها مغلّفة ومعزولة تماماً عن بقية الكود" (MDN Web Docs, Web Components).

هذا التعريف التقني يخفي وراءه ثورة صامتة لكن عميقة الأثر في عالم تطوير الويب. Web Components لم تعد مجرد فضول تجريبي أو تقنية ناشئة. في عام 2026، كل المتصفحات الرئيسية تدعمها أصلياً وبدون أي حاجة لـ polyfills. أطر العمل الحديثة مثل Lit وStencil وFAST تُستخدمها كأساس متين لبنيانها. شركات كبرى مثل Adobe (Spectrum Web Components) وSAP (UI5 Web Components) وبنك ING (Lion Web Components) تبني أنظمة تصميم كاملة ومتكاملة على هذه التقنية.

مع ذلك، يبقى الاختبار البصري لـ Web Components نقطة عمياء حقيقية وملموسة لمعظم الفرق. السبب يعود إلى كلمتين بسيطتين: Shadow DOM.

ما يغيّره Shadow DOM للاختبار البصري

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

Shadow DOM يكسر هذا الافتراض الأساسي بشكل كامل. ينشئ شجرة فرعية DOM معزولة ومستقلة، مُرفقة بعنصر مستضيف، بأنماطها الخاصة والمستقلة. محددات CSS الخارجية لا تستطيع الوصول للعناصر الداخلية. النصوص البرمجية التي تجتاز DOM بـ querySelector لا ترى ما بداخل الظل المحمي.

هذا بالضبط هدف Shadow DOM الأساسي: التغليف والحماية. أنماطك لا تتسرب للخارج، والأنماط الخارجية لا تُلوّث الداخل. إنها ميزة تصميمية قوية وليست خطأ أو قصوراً.

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

ثلاث آليات تعقّد كل شيء

تغليف الأنماط

داخل Shadow DOM، الأنماط محلية. محدد .button في Shadow DOM يستهدف فقط عناصر .button في ذلك Shadow DOM تحديداً. والعكس صحيح أيضاً: أنماطك العالمية لا تنطبق داخل Shadow DOM.

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

الـ Slotting وعرض المحتوى

الـ Slots تسمح لمستخدمي المكون بحقن محتوى داخل Shadow DOM. المكون يعرّف فتحات (<slot>)، والمحتوى من العنصر الأب يُعرض فيها.

بالنسبة للاختبار البصري: المحتوى المُعرَض ينتمي إلى light DOM لكن يُعرض داخل سياق Shadow DOM. يرث بعض أنماط Shadow DOM لكن يبقى تقنياً في light DOM. هذه الازدواجية تخلق مواقف حيث ترى أداة الاختبار العنصر في light DOM لكنها لا تفهم سياقه البصري الفعلي.

CSS Custom Properties

CSS custom properties (متغيرات CSS) هي آلية CSS القياسية الوحيدة التي تعبر حدود Shadow DOM. إذا عرّفت --primary-color: blue على العنصر المستضيف، هذا المتغير متاح داخل Shadow DOM.

هذه هي آلية التخصيص الرئيسية لـ Web Components. المشكلة بالنسبة للاختبار البصري: القيمة الفعلية لخاصية مخصصة تعتمد على سلسلة CSS الكاملة. الكيان الوحيد الذي يحلل هذا بشكل صحيح هو المتصفح نفسه.

لماذا تفشل المناهج الكلاسيكية

الأدوات المبنية على DOM

العديد من أدوات الاختبار تفحص DOM لفهم بنية الصفحة. عند مواجهة Shadow DOM، تصطدم بجدار: العناصر الداخلية غير مرئية عبر واجهات DOM القياسية. معظم الأدوات لم تُبنَ لهذا — أُنشئت حين كان DOM شجرة مسطحة واحدة.

المقارنة بكسل ببكسل

نهج لقطة الشاشة يعمل... على السطح. يلتقط ما يعرضه المتصفح، سواء كان Shadow DOM أم لا. لكنه لا يفهم البنية. إذا تغيّر عرض مكون Web Component بسبب تعديل خاصية موروثة، مقارنة البكسلات تكتشف تغييراً لكنها لا تستطيع تحديد السبب.

محددات CSS في الاختبارات

إذا كتبت اختبارات تتحقق من الأنماط عبر محددات CSS، محدداتك لا تعبر Shadow DOM. يمكنك العمل حول ذلك بتسلسل الوصول إلى shadowRoot، لكن هذا يجعل الاختبارات هشة ومعتمدة على البنية الداخلية للمكون — بالضبط ما يهدف تغليف Shadow DOM لمنعه.

النهج الهيكلي: لماذا يخترق Shadow DOM

نهج الاختبار البصري الهيكلي يتجاوز مشكلة Shadow DOM بأناقة وفعالية مذهلة. لا يحاول قراءة DOM ليخمن ما هو معروض على الشاشة. بدلاً من ذلك، يقرأ خصائص CSS المحسوبة — وهي القيم النهائية الحاسمة التي حسبها المتصفح فعلاً وطبّقها على العنصر بعد حل سلسلة CSS بالكامل.

عندما يعرض المتصفح عنصراً — سواء في light DOM أو Shadow DOM أو مُعرَض عبر slot — يحلل سلسلة CSS الكاملة وينتج قيماً محسوبة ملموسة. لون الخلفية لم يعد "var(--surface-color)" بل "rgb(30, 30, 30)." حجم الخط لم يعد "1.2em" بل "19.2px."

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

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

حالات واقعية حيث يحدث هذا الفرق

التخصيص المكسور

نظام التصميم لديك يعرض --button-bg لتخصيص ألوان الأزرار. فريق يحدّث السمة الرئيسية ويعيد تسمية المتغير إلى --btn-background. جميع أزرار Shadow DOM تفقد لونها المخصص وتعود للقيم الافتراضية.

اختبار هيكلي يكتشف فوراً أن اللون المحسوب للزر تغيّر. اختبار بكسل يكتشفه أيضاً لكن يبلّغ عن تغيير بدون شرح السبب. اختبار DOM لا يكتشف شيئاً لأن المكون متطابق هيكلياً.

Slots بأنماط رديئة

مكون بطاقة يستخدم slot للعنوان. العنوان مُقدَّم من العنصر الأب كـ <h3>. شخص يعدّل أنماط <h3> العالمية دون إدراك أنها تنطبق على العناوين المُعرَضة في البطاقات أيضاً — لأن العناصر المُعرَضة ترث أنماط light DOM للخصائص غير المعرفة في Shadow DOM.

النهج الهيكلي يتحقق من الخصائص المحسوبة لـ <h3> في سياق العرض الفعلي (داخل الـ slot) ويكتشف تغيير الحجم أو الوزن.

مكونات متداخلة

مكون حوار يحتوي مكون نموذج، الذي يحتوي مكونات حقول إدخال. ثلاثة مستويات من Shadow DOM المتداخل. تعديل خاصية مخصصة على مستوى الحوار يجب أن ينتشر عبر المستويات الثلاثة.

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

Web Components وأنظمة التصميم: الضرورة الاستراتيجية

Web Components هي تقنية الاختيار الأولى والمفضلة لأنظمة التصميم الحديثة — مكون Web Component يعمل مع React وAngular وVue أو حتى بدون أي إطار عمل على الإطلاق. إنها قابلة للتشغيل البيني المطلقة والأخيرة.

لكن هذه القابلية للتشغيل البيني الواسعة تخلق تحدي اختبار بصري كبيراً ومعقداً. نظام تصميم Web Components لديك يُستخدم من فرق متعددة ومختلفة، في تطبيقات متعددة ومتنوعة، بسياقات CSS مختلفة تماماً. خطأ بصري واحد في مكون أساسي ينتشر في كل مكان ويؤثر على جميع التطبيقات المعتمدة عليه.

الاختبار البصري لنظام تصميم مبني على Web Components ليس اختيارياً أو ثانوياً بأي شكل. إنه ضمان جودة حاسم وجوهري لجميع الفرق التابعة والمستفيدة. وهذا الضمان يجب أن يعمل بسلاسة عبر Shadow DOM، مع الـ Slots، مع المتغيرات المخصصة، وفي جميع سياقات الاستخدام الممكنة.

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

كيف تتعامل Delta-QA مع Web Components

Delta-QA تستخدم النهج الهيكلي. تقرأ خصائص CSS المحسوبة لكل عنصر مرئي، سواء كان في light DOM أو Shadow DOM أو مُعرَض عبر slot. لا حاجة لتكوين خاص لـ Web Components — الأداة تتعامل معها كأي عنصر مُعرَض آخر.

تحديداً، Delta-QA تتحقق من تباين النص داخل Shadow DOMs، وتكتشف عدم تناسق المسافات بين المكونات، وتحدد انحدارات التخصيص عندما تتغير قيمة متغير مخصص. كل ذلك دون كتابة اختبار، دون محددات CSS محددة، دون وصول صريح إلى shadowRoot.

نصائح عملية للاختبار البصري لـ Web Components

اختبر المكونات منفردة أولاً

قبل اختبار الصفحات الكاملة، اختبر كل مكون في بيئة معزولة (Storybook أو صفحة تجريبية). تحقق من الحالات (الافتراضية والتمرير والتركيز والتعطيل والخطأ) والنسخ (الأحجام والألوان والوضع الفاتح/الداكن).

تحقق من نقاط التكامل

أخطر الأخطاء البصرية تظهر عند نقاط التكامل: حيث يلتقي light DOM بـ Shadow DOM، وحيث يُتداخَل مكون في آخر، وحيث تعبر المتغيرات المخصصة الحدود.

راقب المتغيرات المخصصة

احتفظ بجردة بمتغيرات التخصيص الخاصة بك. النهج الهيكلي يكتشف تلقائياً التغييرات في القيم المحسوبة بغض النظر عن سببها.

أدمج الاختبار البصري في خط أنابيب النشر

كل إصدار جديد من مكون Web Component يجب أن يجتاز الاختبار البصري المؤتمت قبل النشر. انحدار في مكون أساسي له تأثير مضاعف مدمر.

الأسئلة الشائعة

هل Shadow DOM يمنع الاختبار البصري المؤتمت؟

لا، لكنه يمنع بعض المناهج للاختبار البصري. الأدوات التي تفحص DOM لا تستطيع رؤية عناصر Shadow DOM بدون تكيّف محدد. لكن الأدوات التي تقرأ خصائص CSS المحسوبة (النهج الهيكلي) تعبر Shadow DOM بسهولة، لأنها تقرأ القيم النهائية المحسوبة من المتصفح.

كيف تؤثر الـ Slots على الاختبار البصري لـ Web Components؟

الـ Slots تخلق ازدواجية: المحتوى المُعرَض ينتمي إلى light DOM لكن يُعرض في سياق Shadow DOM البصري. الأنماط الموروثة تأتي من الجانبين. أداة اختبار بصري فعّالة يجب أن تتحقق من المظهر الفعلي للعنصر في سياق عرضه النهائي، وليس موضعه في شجرة DOM. النهج الهيكلي يتعامل مع هذا بشكل طبيعي.

هل نحتاج اختبارات بصرية خاصة لـ Web Components؟

لا إذا كانت أداتك تستخدم النهج الهيكلي. قواعد الجودة البصرية (التباين والمسافات والمحاذاة والاتساق) تنطبق بالتساوي على جميع العناصر بغض النظر عن موقعها في DOM. لا تحتاج «اختبارات Web Components خاصة» — تحتاج أداة تعمل في كل مكان.

هل تتطلب Delta-QA تكويناً خاصاً لـ Web Components؟

لا. Delta-QA تحلل خصائص CSS المحسوبة لجميع العناصر المرئية بغض النظر عن موقعها في DOM. عناصر Shadow DOM تُعامَل تماماً مثل أي عناصر أخرى. لا محددات خاصة، لا تكوين shadowRoot، لا نصوص وصول.

هل Web Components تُنشئ انحدارات بصرية أكثر من المكونات التقليدية؟

ليس بطبيعتها، لكن الانحدارات أصعب كشفها بالأدوات الكلاسيكية. تغليف Shadow DOM يخفي التغييرات عن الأدوات غير المُعدَّة. بالإضافة إلى ذلك، التفاعلات بين المتغيرات المخصصة ووراثة CSS والـ slotting تخلق سلاسل اعتماد دقيقة يكون الاختبار البصري المؤتمت في وضع أفضل لمراقبتها من الإنسان.

أي أطر Web Components متوافقة مع الاختبار البصري الهيكلي؟

النهج الهيكلي محايد تجاه إطار العمل. سواء استخدمت Lit أو Stencil أو FAST أو Web Components خالصة، المتصفح ينتج نفس خصائص CSS المحسوبة. Delta-QA تعمل مع جميع أطر Web Components بدون تمييز، لأنها تحلل نتيجة العرض، وليس كود المصدر للمكون.

للمزيد من القراءة

جرّب Delta-QA مجاناً →