كيفية التحقق من الشيفرة المُولَّدة بالذكاء الاصطناعي قبل دمجها

مشكلة مراجعة شيفرة لم تكتبها بنفسك

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

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

الحلقة، في ثلاثة أوامر

ثبّت أداة سطر الأوامر مفتوحة المصدر TestSprite CLI — مجانية، مرخّصة بموجب Apache-2.0، وتحتاج Node 20.19+ أو 22.13+ أو 24+:

npm install -g @testsprite/testsprite-cli
testsprite setup

ثم الحلقة. صف السلوك الذي تريد ضمانه، وشغّله على متصفح حقيقي، واقرأ الحكم من رمز الخروج (exit code):

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

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

لماذا تتفوق مجموعة اختبارات دائمة على نافذة سياق أكبر

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

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

اضبط وكيلك ليقوم بهذا بنفسه

لا ينبغي أن تضطر لنقل الأوامر بين صفحة ويب ووكيل الترميز الخاص بك. أمر إعداد واحد يُثبّت ملف مهارة (skill) داخل المستودع يصف الحلقة بالشكل الذي يستهلكه الوكيل فعليًا:

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

بيئات التشغيل المدعومة هي claude وcodex وcursor وcline وantigravity وkiro وwindsurf وcopilot. التثبيت محلي بالكامل. بعد ذلك، يعرف الوكيل كيفية إنشاء الاختبارات وتشغيلها وفرزها دون الحاجة إلى إخباره مرة أخرى في كل جلسة.

قبل إنفاق دورة على أمر سيفشل لأسباب بيئية، تحقق من البيئة:

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

ما الذي يجب التحقق منه أولًا

لا يستحق كل شيء اختبارًا شاملًا (end-to-end). في قاعدة شيفرة تتغير بسرعة تحت يد وكيل ذكاء اصطناعي، تكون التغطية الأعلى قيمة ضيقة النطاق:

1. التدفقات التي تُنتج إيرادًا. التسجيل، والدفع، والفوترة. الانحدار هنا يكلّف مالًا فورًا وغالبًا ما يكون غير مرئي في اختبارات الوحدة.

2. أي شيء يتعلق بالمصادقة. إدارة الجلسات، وإعادة التوجيه بعد تسجيل الدخول، وحدود الصلاحيات هي حيث تُحدث إعادة هيكلة تبدو معقولة أكبر ضرر.

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

4. آخر ثلاثة أخطاء قمت بشحنها. اختبار الانحدار المكتوب بعد الإصلاح هو الاختبار الأعلى عائدًا في أي مجموعة اختبارات.

إذا كنت تفضّل أن تُقترَح عليك المجموعة الأولى، يمكن للاستكشاف صياغتها. تُعرض المقترحات للمراجعة ولا يُكتب شيء على قرصك حتى تقبلها:

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

جعل الفحص إلزاميًا

خطوة التحقق التي تعمل فقط عندما يتذكر أحدهم تشغيلها ليست تحققًا. ضعها في CI:

testsprite ci init github

ينشئ هذا هيكل .github/workflows/testsprite.yml باستخدام TestSprite/testsprite-action@v1، الذي يُضيف تعليقًا على تبويب فحوصات طلب السحب بخطأ واحد لكل فشل، ويُلحق جدول نتائج بملخص المهمة، ويرفع تقرير JUnit، والأهم — أنه يجعل المهمة تفشل عند تشغيل جزئي بدلًا من الإبلاغ عنها كناجحة.

هذا هو المسار الذي يقود فيه سير عملك التشغيل. يُثبَّت TestSprite أيضًا كتطبيق GitHub يستمع لأحداث النشر التي ينتجها خط الأنابيب لديك بالفعل ويعلّق بالنتائج على طلب السحب، وهو ما لا يحتاج إلى ملف سير عمل ولا إلى أي تغييرات على المستودع على الإطلاق.

في أي نظام CI آخر، لا تحتاج أداة سطر الأوامر إلا إلى مفتاح API في البيئة:

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

رموز الخروج التي تستحق التفريع بناءً عليها

الرموز 129 و130 و143 تعني أن العملية قُوطعت بإشارة (signal) (128 زائد رقم الإشارة)، وليس أن اختبارًا قد فشل — يستحق التمييز قبل الإبلاغ عن تشغيل بأنه معطّل.

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