عن المشروع

تُعد testgraph أداة لاختيار الاختبارات على مستوى رحلة المستخدم (journey-level). بناءً على git diff، تحدد الأداة تدفقات المستخدم التي قد تكون تعطلت بسبب التغيير والترتيب الذي يجب اختبارها به، حيث تعيد قائمة قصيرة مرتبة بدلاً من التوجيه بإعادة تشغيل كل شيء. هي لا تقوم بتشغيل المتصفحات أو إنشاء الاختبارات أو الإصلاح الذاتي؛ بل تتمثل مهمتها في الطبقة التي تعلو المشغلات الحالية، وهي تحديد ما يستحق الاختبار. آلية العمل يقوم سجل الرحلات (journey registry) بتسمية كل رحلة مستخدم ورموز الدخول الخاصة بها، مثل معالجات المسارات (route handlers) أو مسح المجدول. تقوم وحدة propose بصياغة سجل لمستودع جديد عن طريق فحص مزخرفات مسارات Python واتفاقيات Next.js مقابل الفهرس، مع وضع علامة "غير معتمد" (approved false) حتى يراجعه إنسان، لضمان أن السجل غير المعتمد يعمل بشكل ظاهر وليس صامتاً. بالنسبة لـ diff، تقوم testgraph بربط نطاقات الأسطر المتغيرة بالرموز التي تملكها (البذور/seeds)، ثم تتتبع رسم CodeGraph البياني بشكل عكسي وانتقالي إلى كل رمز يعتمد على بذرة (المجموعة المتأثرة)، وتُبلغ عن الرحلات التي تقع رموز دخولها ضمن هذه المجموعة، مرتبة حسب الـ fan-in، حيث تحمل كل منها ثقة أقوى مسار حافة وصل إليها. الثقة هي الحد الأقصى عبر المسارات للحد الأدنى عبر الحواف، لذا فإن السلسلة تكون موثوقة بقدر أضعف قفزة فيها، بينما يكفي مسار واحد صلب. الرحلة التي يتم الوصول إليها فقط عبر حواف ضعيفة أو مُصنعة يتم تمييزها للتحقق اليدوي بدلاً من الثقة بها صامتاً، ولا يتم إزالتها أبداً من الاختيار. الأداة تعطي الأولوية للاسترجاع (recall-first): فهي تفضل الاختيار الزائد على إسقاط رحلة أثرها التغيير فعلياً. وقبل الإجابة، يرفض حارس النزاهة (integrity guard) التشغيل بناءً على فهرس CodeGraph تالف أو قديم، لأن الرسم البياني الخاطئ ينتج إجابة خاطئة بثقة. يتم حل السجل عبر البحث بترتيب الأولوية: متغير بيئة للهروب، ثم دليل .testgraph/journeys داخل المستودع (الموقع الموصى به)، ثم دليل journeys بجانب الحزمة في نسخة المشروع. يتم مطابقة السجل بناءً على هدفه المعلن وليس اسم الملف، ويُرفض أي سجل منسوخ من مشروع آخر دون تعديل. المتطلبات والتثبيت تتطلب Python 3.11 أو أحدث باستخدام المكتبة القياسية فقط، دون تبعيات خارجية؛ وgit لمدخلات diff؛ ومستودع هدف يحتوي على فهرس CodeGraph تم إنتاجه بواسطة codegraph init. يتم التثبيت من PyPI عبر pip install testgraph. تشحن الـ wheel الحزمة وحدها، بينما تعيش أدوات القياس وسجلات dogfood في المستودع. واجهة CLI و MCP تتضمن نقاط الدخول لسطر الأوامر select، بمخرجات مقروءة للبشر أو JSON مخصصة لبوابة CI أو وكيل آخر؛ و export، التي تكتب خريطة رحلات ثابتة يقرأها الوكيل قبل الالتزام (pre-commit)؛ و propose؛ و record؛ ووضع الملخص (summary mode). يوفر خادم MCP stdio أداتين، testgraph_impact و testgraph_journeys، ويتم تسجيله لكل مستودع. يعتمد الخادم على المكتبة القياسية فقط ويستورد وحدات التحليل بشكل كسول (lazily)، لذا فإن الخادم الخامل لا يحمل sqlite3 ولا اتصال قاعدة بيانات ولا يحتفظ بفهرس في الذاكرة. يشير README إلى استهلاك 15.2 ميجابايت RSS بعد مصافحة كاملة، مقابل 62 إلى 69 ميجابايت لخادم Python MCP SDK نموذجي. الربط والدفتر (The Ledger) يقوم hooks/install.sh بتثبيت pre-push hook في كل مستودع لديه سجل معتمد، بحيث تطبع كل عملية push الرحلات التي قد تكون تعطلت. يقوم الـ hook بتشغيل codegraph sync أولاً، لأن البذور تأتي من نطاقات الأسطر، وأي فهرس بُني قبل نقل الكود سيحل diff مقابل نطاقات قديمة؛ وإذا كانت بايتات الملف المتغير لا تزال تختلف عن النسخة المفهرسة، تتدهور الإجابة وتسمي الملف. لا يتسبب الـ hook أبداً في فشل الـ push، حيث تخرج جميع المسارات بالقيمة صفر، ويمكن تعطيله لكل مستودع عبر إعداد git config أو إزالته بعلامة uninstall. تضيف كل عملية تشغيل صف اختيار واحد إلى دفتر JSONL؛ ويقوم الأمر record بكتابة النصف الآخر (ما وجده تشغيل الرحلة)، بحيث يمكن عند دمج الاثنين بناءً على المستودع والالتزام (commit) حساب الرحلة التي فشلت في التزام لم يذكرها الاختيار، وهو ما يوصف بأنه نقص اختيار صامت (silent under-selection). الحالة تُوصف الأداة بأنها مرحلة-1 spike بالإضافة إلى مسارات موزونة بالثقة، تعمل ومثبتة على هدف dogfood واحد: استرجاع (recall) بنسبة 1.00 عبر خمسة التزامات مصنفة يدوياً بمتوسط دقة 0.68، و 1.00 عبر عشرين موقع طفرة (mutation sites) تم تقييمها مقابل AST oracle مستقل، مع اختبار حارس النزاهة وتثبيت المخطط (schema-pinned). النطاق هو هذا الهدف الوحيد، حيث يتم تحليل ملفات الخلفية (backend) والواجهة الأمامية (frontend) مع رحلات مسجلة على نقاط دخول الخلفية. يسجل README أيضاً أن القياسات اللاحقة على مستودعين بدون سجل قد أبطلت ادعاءات التوفير السابقة: في مستودع يحتوي على 23 رحلة، ظهر مخطط بياني لصفر رحلات لـ 38 التزاماً و 23 رحلة لالتزامين، وفي مستودع آخر بـ 207 رحلة، تم تجنب 54.1% فقط من تشغيلات الرحلات بمجرد استبعاد الالتزامات التي لم تلمس أي سطح مسجل، لذا يجب قراءة أرقام الاختيار كحد أدنى للارتباط (coupling) وليس كوعد بالتوفير. وأكد القياس نفسه الترتيب، حيث تم تمييز اختيار السجل الكامل كإيجابي كاذب للتحقق اليدوي بثقة 0.3، بينما ظهر نطاق تأثير واسع وحقيقي بنظافة عند 0.9.