توقفوا عن اختبار الكود، وابدأوا اختبار ما يهم حقاً: نهج "البوابة التفاضلية

توقفوا عن اختبار الكود، وابدأوا اختبار ما يهم حقاً: نهج "البوابة التفاضلية"

خليني أحكي لكم عن اليوم اللي اكتشفت فيه إن نجاح الاختبارات مش معناه إن البرنامج شغال.

الساعة 3 فجراً، لوحة المراقبة بتصيح أحمر. منصة التجارة الإلكترونية عندنا بدأت تخصم من العملاء مرتين عن كل عملية شراء. السبب؟ وكيل كود ذكي اصطناعي "صلح" حالة تنافس (race condition) في طبقة معالجة الدفع. كل اختبارات الوحدة (unit tests) نجحت. اختبارات التكامل (integration tests) خضرا. لكن المستخدمين الحقيقيين اتحاسبوا مرتين، وفريق الدعم غرق في مكالمات غاضبة.

وقتها فهمت إننا كنّا نختبر حاجة غلط تماماً.

المشكلة مع الاختبارات التقليدية

لما نعتمد على مجموعات اختبارات مكتوبة مسبقاً عشان نتحقق من تصحيحات الوكلاء الذكيين، نحن في الأساس بنسأله: "هل الكود الجديد يتصرف زي الأمثلة اللي فكّرت فيها؟" لكن السر القذر اللي مفيش حد عايز يعترف به — أغلب مجموعات الاختبارات بتغطي تقريباً ٦٠-٧٠٪ من أنماط الاستخدام الفعلية. الـ ٣٠٪ الباقية؟ دي مكان مستخدمينك، ودي المكان اللي الأشياء بتتكسر فيه.

الاختبارات التقليدية بتركز على بنية الكود والنتائج المتوقعة بناءً على افتراضات المطورين. لكن في الإنتاج، المستخدمين بيعملوا حاجات غريبة. يضغطوا أزرار بترتيب غير متوقع، يتركوا النماذج نص مملوءة، يستخدموا متصفحات مسمعتيش بيها، ويكتشفوا حالات حافة (edge cases) تخلي اختباراتك المحكمة دي تبدو زي لعب عيال.

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

ادخلوا "البوابة التفاضلية"

هنا بييجي الاختبار التفاضلي — مش النوع الأكاديمي اللي بتقراه في أوراق البحث. أتكلم عن نهج عملي، مجرب في المعركة، أسميه "البوابة التفاضلية".

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

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

إزاي بتشتغل في الممارسة

خليني أمشيكم في ثلاثة سيناريوهات حقيقية النهج ده أنقذنا فيها:

السيناريو ١: باگ إعادة التوجيه الصامت

استأجرنا وكيل ذكي يعيد هيكلة الوسيط (middleware) للمصادقة. الكود كان نظيف، كل الاختبارات نجحت، والفرق (diff) كان بسيط. لكن لما شغلنا بوابتنا التفاضلية، قبضت على حاجة خفية — الوكيل غير طريقة بناء روابط إعادة التوجيه. بدل `https://app.example.com/dashboard`، كان بيولد `https://example.com/app/dashboard`،.

بالنسبة للمستخدم، معناه إنه يعمل تسجيل دخول بس يخلص في صفحة فاضية. اختباراتنا التقليدية ماكنتش تغطي بناء روابط إعادة التوجيه لأننا "كنا واثقين" إن الإطار (framework) هيتصرف فيها. البوابة التفاضلية ما وثقتش في حاجة.

السيناريو ٢: تراجع الأداء

وكيل ذكي حسّن مسار معالجة الصور. أوقات الاستجابة تحسنت ٤٠٪ في اختبارات الأداء (benchmarks) بتاعتنا. لكن لما أعدنا تشغيل ترافيك الإنتاج من خلال بوابتنا التفاضلية، لاحظنا حاجة مقلقة — تنسيقات صور نادرة الاستخدام في مجموعة اختباراتنا فجاءة بقت تاخد ٥ أضعاف الوقت للمعالجة.

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

السيناريو ٣: كسر عقد API

فريقنا استخدم وكيل ذكي يطور REST API قديم. الوكيل حول المكالمات المتزامنة (synchronous) لغير متزامنة (asynchronous)، حسن الإنتاجية (throughput) بشكل ملحوظ. كل الاختبارات الموجودة نجحت لأنها محاكات (mocked) السلوك غير المتزامن بشكل صحيح. لكن لما أعدنا تشغيل مكالمات API حقيقية من خلال بوابتنا التفاضلية، اكتشفنا إن توقيت الاستجابة اتغير بشكل دراماتيكي.

التكاملات الخارجية اللي كانت بتعتمد على نوافذ مهلة (timeout) محددة بدأت تفشل. عقد API مش كان عن البيانات المرتجعة — كان عن توقيت الاستجابات. الاختبار التقليدي فوّت ده تماماً.

بناء بوابتك التفاضلية الخاصة

عمل بوابة تفاضلية مش علم صواريخ، بس محتاج انضباط. كذا بنيناها:

الخطوة ١: التقاط ترافيك حقيقي

جهزنا بيئة الإنتاج تسجل كل تفاعل مستخدم، وكل مكالمة API، وكل استعلام قاعدة بيانات. مش عن مراقبة — عن إنشاء مجموعة بيانات ذهبية من السلوك الفعلي. بنستخدم أدوات زي **OpenTelemetry** عشان نلتقط التتبعات الموزعة (distributed traces)، ونخزن البيانات دي في قاعدة بيانات وقتية (time-series database) لسهولة إعادة التشغيل.

الخطوة ٢: إنشاء بيئتين جنب بعض

لكل تصحيح، بنشغل بيئتين متطابقتين — واحدة تشغل الكود القديم، وواحدة تشغل الكود الجديد. بنستخدم مساحات الأسماء (namespaces) في Kubernetes لعزل البيئات دي والتأكد إنهم متطابقين في كل حاجة عدا الكود اللي بينختبر.

الخطوة ٣: إعادة التشغيل والمقارنة

بناخد ترافيكنا الملتقط ونعيد تشغيله ضد البيئتين في نفس الوقت. محرك المقارنة عندنا بيدور على اختلافات في:
- محتوى وبنية الاستجابة
- توقيت الاستجابة
- معدلات وأنواع الأخطاء
- أنماط استعلامات قاعدة البيانات
- مكالمات API الخارجية

أي اختلاف ذو دلالة إحصائية بيتعلم للمراجعة البشرية.

الخطوة ٤: الإشراف البشري

الرؤية الأساسية هنا إننا ما بنمنعش التصحيحات اللي فيها اختلافات تلقائياً. بنعلمها للحكم البشري. أحياناً التغيرات السلوكية بتكون تحسينات مقصودة. أحياناً بتكون باگات كارثية مختبئة وراء نتائج اختبارات نظيفة.

الأدوات والتقنيات

محتاجش تبني كل حاجة من الصفر. هنا أدوات خلت بوابتنا التفاضلية ممكنة:

**ReplayProxy** (github.com/replayproxy/replayproxy) — إطار عمل مفتوح المصدر لالتقاط وإعادة تشغيل الترافيك
**Diffy** (github.com/twitter/diffy) — أداة تويتر للاختبار التفاضلي، مثالية لمقارنة APIs
**Polly** (github.com/Polly-HTTP/Polly) — أداة هندسة فوضى (chaos engineering) تساعدك تختبر المرونة

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

تخليها تمشي في منظمتك

تطبيق بوابة تفاضلية محتاج موافقة (buy-in) من فريقك بالكامل. كذا بعناها:

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

ثانياً، وضعناها كتحسين لسرعة المطورين. بدل ما يقضوا ساعات يكتبوا حالات اختبار شاملة، المطورين يقدروا يركزوا على تحسينات ذات مغزى بينما البوابة بتتعامل مع التحقق.

ثالثاً، خليها غير مؤلمة. البوابة متكاملة مباشرة في خط أنابيب CI/CD بتاعنا. كل طلب سحب (pull request) بيطلق اختبار تفاضلي تلقائي ضد نسخة الإنتاج الحالية. النتائج بتظهر في Slack خلال دقائق.

مستقبل التطوير بمساعدة الذكاء الاصطناعي

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

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

بتنبأ إن خلال خمس سنين، كل فريق تطوير جاد هيعمل شكل من أشكال الاختبار التفاضلي في خط أنابيبه. اللي يعتمدوه بدري هيسلموا برامج أكتر موثوقية بثقة أعلى. اللي يتمسكوا بالاختبار التقليدي هيفضلوا يجرّوا باگات اختباراتهم ما قبضت عليهاش أبداً.

البوابة التفاضلية مش بس عن पकد باگات — عن بناء ثقة في التطوير بمساعدة الذكاء الاصطناعي. لما تقدر تثبت إن تصحيح الوكيل بيغير بالظبط اللي نويت تغيره وما يغيرش حاجة تانية، بتفتح الإمكانية الحقيقية للتطوير التعاوني بين الإنسان والذكاء الاصطناعي.

ابدأ صغير. التقط جزء من ترافيكك. قارن قبل وبعد. هتتعرج مما تكتشف.

---

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

**س: مش هايبطئ الاختبار التفاضلي عملية النشر عندنا؟**
ج: في البداية، أيوه — لكن المقايضة تستاهل. قللنا وقت الاستجابة للحوادث من ساعات لدقايق، ووفرنا وقت أكتر بكتير من اللي بنقضيه على الاختبار التفاضلي.

**س: محتاجين نلتقط ١٠٠٪ من ترافيكنا لاختبار تفاضلي فعال؟**
ج: لأ، لكن عايزين تغطية تمثيلية. ركز على نقاط النهاية (endpoints) عالية الترافيك وتدفقات المستخدم الحرجة الأول. حتى ١٠-٢٠٪ من ترافيك الإنتاج يقدر يكشف معظم تراجعات السلوك.

**س: إزاي نتعامل مع التغيرات السلوكية المقصودة في بوابتنا التفاضلية؟**
ج: سؤال ممتاز! بنعلّم التصحيحات ببيانات وصفية (metadata) بتدل على هل التغيرات السلوكية متوقعة. التغيرات المقصودة بتتجاوز قواعد مقارنة معينة، بينما التغيرات غير المتوقعة بتطلق تنبيهات فورية.

**س: يقدر الاختبار التفاضلي يشتغل مع معماريات الخدمات المصغرة (microservices)؟**
ج: تماماً. في الحقيقة، قيمته بتزيد في الأنظمة الموزعة حيث نقاط التكثثف عديدة ومعقدة. بنشغل بوابات تفاضلية على مستوى الخدمة وعلى مستوى النهاية للنهاية (end-to-end).