← All posts

نجاح اختبارات الوحدة لا يعني أنك جاهز للإطلاق

Authagonal·June 23, 2026
testingplaywrighte2edotnet

نحن نبيع المصادقة، وهذا ما يجعل أكثر أسئلتنا إرعاباً سؤالاً بسيطاً: عندما يربط عميل تطبيقه بنا ويشغّل كل شيء، هل يعمل الأمر فعلاً، من البداية إلى النهاية، على المنتج الحقيقي؟ ليس "هل تنجح اختبارات الوحدة"، بل هل يسجّل مستأجر جديد تماماً، ويضبط SSO وSCIM وMFA والمطالبات المخصّصة والعلامة التجارية، ويوجّه تطبيقاً حقيقياً إليه، ويسجّل دخول مستخدم حقيقي بالمطالبات الصحيحة داخل الرمز، عبر متصفّح حقيقي. نحن نجيب عن ذلك بالطريقة الوحيدة التي نثق بها: باختبار واحد شامل من البداية إلى النهاية يتحوّل إلى عميل.

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

يضبط كل شيء، لا شريحة من المسار السعيد فقط

منتصف الاختبار شامل عن قصد. فهو لا يسجّل الدخول ويعتبر المهمة منتهية؛ بل يمرّ بكل شاشة يلمسها مُنفّذ حقيقي ويختبرها فعلياً: عميل OIDC مخصّص مع عناوين إعادة التوجيه وإعدادات الرمز الخاصة به، ونطاق مخصّص يصدر مطالبات المستخدم، وأدوار وإسناد دور، ومستخدم نهائي بسمة مخصّصة، ومجموعة بعضوية حقيقية وربط من المجموعة إلى الدور، واتصالات مؤسسية عبر SAML وOIDC، ورمز توفير SCIM، ونطاق مخصّص، وتطبيق توفير صادر، وزميل تتم دعوته وتغيير دوره، والفوترة عبر عملية دفع حقيقية، وسجل التدقيق مع المرشّحات وتصدير CSV، وبيئة اختبار معزولة، وإعدادات الأمان وwebhook والبريد الإلكتروني (كل منها يُقلَب ثم يُعاد إلى حالة آمنة). كل واحد من هذه يُنشأ ويُتحقّق منه، وحيثما كان منطقياً يُحذف، في التشغيلة نفسها.

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

رقصة بيانات الاعتماد

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

لذلك يفعل الاختبار تماماً ما يفعله مُنفّذ حقيقي، لكن أسرع. ينشئ عميل OIDC في البوابة ويقرأ منها مُعرّف العميل والسرّ. ويصكّ بيانات اعتماد Portal API بنقرة واحدة ويلتقطها. ويولّد رمز SCIM. ثم يغذّي كلّاً من هذه الأسرار الطازجة في تطبيق المستهلك النموذجي الجاهز، ويعيد كتابة إعدادات ذلك التطبيق بالقيم الجديدة، وينشره، وعندها فقط يقود عملية تسجيل الدخول الفعلية. بيانات اعتماد تُولد في خطوة تُحقَن في التطبيق قيد الاختبار في الخطوة التالية، ويُكمل المتصفّح إعادة توجيه OIDC حقيقية مقابلها. التكامل هدف متحرّك يظلّ الاختبار يعيد تصويبه على نفسه كلما اتخذ شكله.

ذلك المستهلك نشرٌ حقيقي، لا نموذج محاكاة. عندما يتحقّق الاختبار من عملية تسجيل دخول، يكون تطبيق حقيقي قد أعاد التوجيه فعلاً إلى مُصدِر المستأجر، وحصل فعلاً على رمز مؤقت، وتبادله فعلاً، ويفكّ الاختبار تشفير الرمز الناتج ليؤكّد أن المطالبة المخصّصة والدور المربوط موجودان فيه حقاً. ثم يقود الحواف الأصعب: صفحة تسجيل دخول بعلامة تجارية مخصّصة خلف بوابة تفعيلها، وwebhook مُفروض يجب أن يحجب عملية تسجيل دخول ترفضها السياسة. اختبار أخضر على هذا الأخير يعني أن مسار الرفض يعمل، وهي النتيجة التي تريد أن تكون متأكّداً منها أكثر من غيرها.

المصادقة متعدّدة العوامل، على الحقيقة

تسجيل دخول بكلمة مرور يثبت القليل بمفرده. التشغيلة تسجّل ثم تستخدم مصادِق TOTP وبيانات اعتماد WebAuthn عبر مصادِق افتراضي، فيُختبر العامل الثاني بالطريقة التي يُختبر بها لدى مستخدم حقيقي، لا مُستبدلاً بنسخة وهمية.

النصف الذي يتخطّاه الجميع: استعادتها

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

لماذا هذا هو الاختبار الذي نثق به

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

كل ميزة تختبرها هذه التشغيلة (SSO وSAML، وSCIM، وMFA، والمطالبات والنطاقات المخصّصة، والعلامة التجارية، وwebhooks المفروضة، وتصدير سجل التدقيق) موجودة في المنتج في كل مستوى، وليست محجوبة خلف بيع إضافي للمؤسسات. اطّلع على ما هو مشمول.