Hurl

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

🧭 ما Hurl وكيف تعمل؟

Hurl مشروع مفتوح المصدر من Orange-OpenSource، مكتوب بلغة Rust ويستخدم libcurl لإرسال الطلبات. تكتب عنوان الطلب وطريقته، ثم رمز الاستجابة المتوقع وشروطًا على الرؤوس أو المحتوى. امتداد الملف المعتاد .hurl، ويمكن أن يضم طلبًا واحدًا أو سلسلة طلبات مرتبطة. لا تحتاج إنشاء مشروع برمجي كامل لكتابة فحص بسيط.

HTTP هو بروتوكول تواصل العميل مع الخادم، وAPI هي الواجهة التي يعرضها تطبيقك لقراءة البيانات أو تعديلها. أما Assertion فهو شرط يحدد ما تعتبره صحيحًا: ليس فقط أن الخادم أعاد 200، بل أن الحقل المطلوب موجود وقيمته توافق عقد الواجهة. JSONPath طريقة لاختيار حقل داخل JSON؛ مثل $.status لاختيار حقل status في المستوى الأول.

Hurl ليست متصفحًا ولا تنفذ JavaScript الخاص بواجهة الموقع. هي تفحص الطلب والرد على مستوى HTTP، ولذلك تناسب واجهات البيانات والصفحات التي يرسلها الخادم، لا اختبار موضع زر أو تفاعل واجهة كامل.

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

🎯 كيف ستفيدك وما القيمة المضافة؟

تناسب مطورًا أو فريقًا صغيرًا لديه API ويكرر سيناريوهات مثل فحص الخدمة، إنشاء سجل ثم قراءته، أو التحقق من رفض طلب غير مصرح. بدل حفظ قائمة خطوات في المحادثة، تحول المطلوب إلى ملف يمكن مراجعته في Git وتشغيله بالأمر نفسه. وعندما يغير وكيل برمجة endpoint، يستطيع تشغيل الفحص المعتمد إذا سمحت له بذلك؛ Hurl نفسها لا تستخدم نموذج AI ولا تتطلب مفتاحه.

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

🌟 الميزات وطريقة استخدامها

1. اختبر المحتوى، وليس مجرد نجاح الاتصال

اكتب HTTP 200 بعد الطلب لتحديد الرمز المتوقع، وأضف [Asserts] للشروط التفصيلية. يمكنك اختيار حقل JSON أو رأس استجابة، ثم مقارنته بقيمة، أو فحص وجوده أو عدد العناصر. النتيجة المفيدة هي اكتشاف رد يبدو ناجحًا على مستوى النقل لكنه يخالف العقد المطلوب.

• أين تجدها: داخل ملف .hurl، بعد الطلب وقسم الاستجابة المتوقع.
• كيف تستخدمها: ابدأ بفحص الرمز، ثم أضف شرطًا على أهم معلومة يعتمد عليها عميلك. مثلًا jsonpath "$.status" == "ok" إذا كانت الواجهة الفعلية تعيد هذا الحقل بهذه القيمة.
• مثال توضيحي: فحص /api/health يتوقع رمز 200 وقيمة ok في status. إذا كان خادمك يعيد healthy أو بنية مختلفة، عدّل الشرط وفق العقد؛ Hurl لا يعرف معنى الصحة من اسم المسار.
• القيد: تحقق من نوع القيمة أيضًا عند الحاجة؛ الرقم والنص ليسا دائمًا الشيء نفسه. لا تجعل مجرد وجود الحقل دليلًا على صحة المبلغ أو الصلاحيات أو حساب الربحية. كل قاعدة مهمة تحتاج شرطًا يعبر عنها.

الرسم يلخص شروطًا توضيحية، وليس تقرير نجاح من تجربة منفذة.

2. استخرج قيمة من رد واستخدمها في الطلب التالي

تحتاج كثير من السيناريوهات معرفًا يعيده الخادم: تنشئ طلبًا ثم تقرأ الطلب نفسه، أو تحصل على رمز حماية ثم ترسله مع طلب لاحق. قسم [Captures] يستخرج القيمة ويسميها، ويمكن استعمالها لاحقًا بصيغة {{order_id}}. بذلك لا تنسخ المعرف يدويًا ولا تعتمد على رقم ثابت قد يتغير.

• أين تجدها: قسم [Captures] في الاستجابة، ثم قالب المتغير في الطلب اللاحق.
• كيف تستخدمها: اكتب order_id: jsonpath "$.id" إذا كان الرد يحتوي المعرف في id، ثم أرسله في مسار القراءة. احتفظ بالخطوات المرتبطة داخل الملف نفسه ليكون تسلسلها واضحًا.
• مثال توضيحي: POST /api/orders يعيد سجلًا، ثم GET /api/orders/{{order_id}} يقرأه. يتحقق الاختبار من الاسم المتوقع بعد القراءة، وليس من إنشاء سجل آخر صدفة.
• القيد: القيم المستخرجة تعيش في جلسة التشغيل، وتعريف الاسم نفسه مجددًا يستبدل قيمته السابقة. لا تصمم ملفات مستقلة على افتراض أنها تتبادل captures تلقائيًا. وإذا كان الطلب الأول يكتب بيانات، فإن إعادة تشغيل السيناريو قد تنشئ بيانات أخرى.

رسم توضيحي لعلاقة الاعتماد بين الطلبات؛ لم ينفذ السيناريو على نظام فعلي.

3. شغّل ملفات الاختبار واحتفظ بتقرير قابل للمراجعة

الأمر hurl --test يعرض ملخص اختبار بدل إخراج جسم الاستجابة الأخيرة المعتاد. الشروط تنفذ بوجود هذا الخيار أو بدونه؛ الخيار يغير نمط العرض والتشغيل ولا يخلق شروطًا غير مكتوبة. في وضع الاختبار تعمل الملفات بالتوازي افتراضيًا، بينما تظل الطلبات داخل الملف الواحد متتابعة.

• أين تجدها: خيارات سطر الأوامر --test و--jobs وخيارات التقارير.
• كيف تستخدمها: شغّل مجلد الاختبارات بعد مراجعته. استخدم --jobs 1 إذا احتجت تنفيذ الملفات واحدًا بعد الآخر. يمكن توليد تقارير HTML وJSON وJUnit وTAP لعرض النتيجة أو قراءتها من نظام CI.
• مثال توضيحي: شغّل health.hurl وorders.hurl على بيئة اختبار، واحفظ تقرير HTML في مجلد مخصص لهذه الجولة. اقرأ الخطأ ورقم السطر ثم أصلح السبب، ولا تغير القيمة المتوقعة لمجرد جعل الاختبار ينجح.
• القيد: لا تجعل ملفين متوازيين يعدلان السجل نفسه. التقارير قد تحتوي ملفات الاختبار ومحتوى الردود، وإعادة استعمال مجلد تقرير قائم قد تضيف أو تحدث النتائج بدل أن تبدأ سجلًا فارغًا. عزل بيانات الاختبار والتقارير مسؤوليتك.

مخطط توضيحي، وليس صورة لواجهة التقرير أو قياسًا لسرعة التنفيذ.

🪜 مثال عملي: أنشئ طلبًا ثم تحقق من قراءته

مثال توضيحي غير منفذ. يفترض المثال وجود API تجريبي تملكه على http://localhost:3000؛ فحص الصحة يعيد {"status":"ok"}، وإنشاء الطلب يقبل name ويعيد id، والقراءة تعيد الاسم نفسه. هذه مسارات وعقود افتراضية وليست endpoints تقدمها Hurl.

احفظ الملف التالي باسم orders.hurl:

GET {{base_url}}/api/health
HTTP 200
[Asserts]
jsonpath "$.status" == "ok"

POST {{base_url}}/api/orders
Content-Type: application/json
{
  "name": "Hurl demo"
}
HTTP 201
[Captures]
order_id: jsonpath "$.id"
[Asserts]
jsonpath "$.id" exists

GET {{base_url}}/api/orders/{{order_id}}
HTTP 200
[Asserts]
jsonpath "$.name" == "Hurl demo"

ثم اتبع المسار:

1. شغّل خادمك التجريبي وتأكد من قواعد الوصول وصيغة الردود. إذا احتاج مصادقة فأضف حساب اختبار محدود الصلاحية؛ حذف المصادقة من التطبيق ليس حلًا لكتابة اختبار أسهل.
2. اقرأ الملف كاملًا قبل التشغيل. الطلب POST يكتب بيانات؛ لا توجه هذا المثال إلى الإنتاج أو إلى خدمة لا تملك إذن اختبارها.
3. مرر عنوان البيئة كمتغير بدل نسخه داخل كل طلب:

hurl --test --variable base_url=http://localhost:3000 orders.hurl

1. راجع ملخص الاختبار والخطأ الفعلي. بحسب الدليل، رمز الخروج 0 نجاح، و2 خطأ تحليل الملف، و3 خطأ تشغيل مثل تعذر الاتصال، و4 فشل شرط. ميز انقطاع الخادم عن اختلاف الرد بدل تعديل الاختبار عشوائيًا.
2. لتوليد تقرير لجولة مستقلة استخدم مجلدًا جديدًا، مثل:

hurl --test --variable base_url=http://localhost:3000 \
  --report-html reports/orders-demo orders.hurl

1. راجع البيانات التي أنشئت ونظفها بالطريقة المعتمدة في تطبيقك. لا يفترض المثال وجود rollback تلقائي. احفظ ملف الاختبار في Git بعد إزالة الأسرار، ولا تنشر التقرير قبل فحصه.

النتيجة المقصودة فحص مترابط يمكن تكراره، وليس وعدًا بأن هذه الأوامر ستنجح دون API يطابق الافتراضات. لم أثبت Hurl أو أرسل هذه الطلبات ولم أقس زمنًا أو معدل نجاح.

⚖️ ماذا تضيف مقارنة بالعمل اليدوي؟

Hurl لا تلغي أدوات الاستكشاف الرسومية، وقد يكون طلب curl واحد كافيًا لفحص عابر. فائدتها أوضح عندما أصبح لديك سيناريو متكرر تريد تثبيت خطواته ومعيار نجاحه. ويمكن تنظيم أمر التشغيل داخل Task، لكن هذا نمط تركيب بين الأدوات وليس تكاملًا خاصًا مطلوبًا.

⚙️ الإعدادات التي تحتاجها أولًا

مرر القيم غير السرية مثل عنوان البيئة بـ--variable، أو استخدم --variables-file لملف name=value، أو متغيرات البيئة المدعومة. لا تضع رمز الإنتاج في ملف الاختبار. وتسمح [Options] بتغيير سلوك طلب بعينه، مثل اتباع التحويلات، بدل تطبيق الخيار على كل الطلبات.

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

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

🚀 التثبيت والتوافق

على macOS مع Homebrew، الأمر الرسمي هو:

brew install hurl
hurl --version

تتوفر ملفات تنفيذية لـmacOS بمعماريتي Intel وARM، إضافة إلى Linux وWindows. توضح وثائق الإصدار أن Windows يحتاج Visual C++ Redistributable منفصلًا، وأن نسخة Linux التنفيذية المشار إليها تتطلب libc 2.35 أو أحدث. اختر حزمة توافق بيئتك؛ لا يعني دعم Linux أن كل توزيع أو معمارية يوافق الملف نفسه.

الحزمة الجاهزة لا تحتاج مشروع Rust أو Python لتشغيلها. أما البناء من المصدر فله اعتماديات أصلية مثل libcurl وlibxml2 وlibssl بحسب النظام، ويحدد manifest للإصدار المتحقق Rust 1.95.0. للمستخدم الذي يريد البدء، مدير الحزم أو الملف الجاهز أبسط من البناء اليدوي.

أحدث إصدار مستقر أعادته واجهة GitHub وقت الفحص هو 8.0.1، ونُشر الإصدار في 29 أبريل 2026؛ يسمي سجل التغييرات النسخة بتاريخ 28 أبريل. لم أستبدل تاريخ الإصدار بتاريخ كتابة البطاقة، ولم أنفذ التثبيت هنا. قد تعرض بعض صفحات الموقع مثالًا لإصدار 8.0.0؛ ملفات الإصدار 8.0.1 هي المرجع المثبت لهذه البطاقة.

🔗 التكاملات وحدود التغطية

يمكن تشغيل Hurl من خط CI بعد تجهيز التطبيق وبيئة الاختبار، ثم حفظ تقرير JUnit أو HTML. تستطيع فحص REST وSOAP وGraphQL لأنها طلبات HTTP، وفحص JSON أو XML أو HTML المرسل من الخادم. دعم بروتوكول أو ميزة نقل معينة قد يعتمد على بناء libcurl الذي تستخدمه؛ افحص hurl --version والوثائق لبيئتك.

الأداة لا تنقر أزرارًا ولا ترسم الصفحة ولا تختبر ناتج JavaScript في المتصفح. اختبارات واجهة المستخدم تحتاج أداة متصفح منفصلة. وهي ليست مدير مشاريع أو خادم API أو أداة تكتشف كل ثغرة تلقائيًا. يمكنك كتابة حالات رفض الوصول والتحقق من المدخلات، لكن تغطية الصلاحيات تعتمد على الحالات التي صممتها.

💰 التكلفة والتشغيل المحلي

Hurl بترخيص Apache-2.0، واستخدام سطر الأوامر محليًا لا يحتاج اشتراك Hurl أو API مدفوعًا. تظل تكلفة الخادم ووقت CI وأي خدمة تختبرها منفصلة. يمكنك توجيه الطلبات إلى خادم محلي، لكن اختبار خدمة بعيدة يتصل بها ويرسل الرؤوس والمحتوى الذي حددته.

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

🔐 الخصوصية والصلاحيات

تعامل مع ملف الاختبار كتعليمات تشغيل حقيقية: يمكن أن يرفع ملفًا محليًا أو ينشئ أو يعدل بيانات بالخادم وفق الطلبات وصلاحية الحساب. استخدم بيئة اختبار وحسابًا محدودًا، وراجع أي ملف يأتيك من مصدر آخر قبل تمرير مفاتيحك إليه. يظل التحقق من TLS مفعلًا وفق الإعداد السليم؛ لا تعتمد تعطيله لحل مشكلة شهادة.

تدعم Hurl إخفاء قيم الأسرار في السجلات والتقارير عبر --secret، ويمكن جعل capture ديناميكي سريًا بإضافة redact إلى آخر استعلامه. هذا إخفاء عرض وليس تشفيرًا أو خزنة أسرار؛ القيمة لازمة لإرسال الطلب أصلًا، وتمرير سر صريح في الأمر قد يتركه في سجل الطرفية أو يكشفه في بيئة العملية. راجع طريقة حقن الأسرار الموثقة في بيئة CI ولا تحفظها في Git.

التقارير، ملفات الاستجابة، cookie jars وسجلات verbose قد تحتوي بيانات حساسة. راجعها قبل مشاركتها أو جعل artifacts عامة، ولا تفترض أن إخفاء قيمة واحدة يمسح كل بيانات العميل. لم أجر تدقيقًا أمنيًا مستقلًا أو تجربة على بيانات حقيقية.

⚠️ متى لا تناسبك؟

إذا أردت تجربة طلب وحيد بسرعة فقد يكفي curl أو عميل رسومي. وإذا كان المطلوب اختبار رحلة مستخدم داخل React أو Vue بعد تنفيذ JavaScript فلا تكفي Hurl. وللسيناريوهات التي تحتاج تهيئة بيانات معقدة أو تنظيفًا مضمونًا بعد الفشل، ستحتاج تنظيمًا إضافيًا لبيئة الاختبار؛ الأداة لا تنشئ هذا التنظيم عنك.

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

📚 المصادر وتاريخ التحقق

التحقق: 17 أكتوبر 2026. المستودع الأصلي · الإصدار 8.0.1 · README المثبت للإصدار · التثبيت · التشغيل والتقارير · Captures والأسرار · الترخيص.

أعادت واجهة GitHub الرسمية 19,258 نجمة و750 تفرعًا وقت الرصد، وآخر دفع ظاهر في 17 أكتوبر 2026. الأرقام متغيرة وليست تقييم مستخدمين أو شهادة أمان. لم أوثق عدد التنزيلات، ولم أشغّل المثال.

شمل الاكتشاف GitHub Topics ومستودعات الناشرين وdshmarket.com؛ تعذر تحميل claudeskills.info في المحاولة الحالية. قورنت Hurl مع PocketBase من مجال الخوادم الخلفية الخفيفة، ذي ترخيص MIT وإصدار ظاهر v0.40.5 مع تنبيه رسمي لعدم ضمان التوافق الكامل قبل 1.0. اختيرت Hurl لمهمة أضيق يمكن إضافتها إلى مشروع قائم: تحويل فحص HTTP المتكرر إلى اختبار نصي، وليس لأن عدد نجومها أعلى.