DEV Community

Cover image for أفضل أدوات CLI خفيفة لاختبار API
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

أفضل أدوات CLI خفيفة لاختبار API

تطلب منك معظم أدوات اختبار API فتح نافذة، وتسجيل الدخول، والتنقل داخل مساحة عمل قبل إرسال أول طلب. هذا مناسب للاستكشاف المرئي، لكنه لا يناسب المحطة الطرفية: تريد كتابة أمر واحد، قراءة الاستجابة، ثم المتابعة. في أدوات CLI الخفيفة، الطلب نفسه هو واجهة التفاعل.

جرّب Apidog اليوم

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

في هذا الدليل ستجد ثماني أدوات CLI لاختبار REST وHTTP، من الطلبات اليدوية السريعة إلى تشغيل مجموعات اختبار كاملة في CI. يتضمن كل قسم أمر تثبيت، ومثالًا قابلًا للتنفيذ، وحالة الاستخدام المناسبة، والقيود العملية.

ما الذي يجعل أداة CLI خفيفة الوزن لاختبار API؟

ليست كل أداة تعمل في المحطة الطرفية خفيفة فعلًا. استخدم هذه المعايير قبل اختيارها:

  • بصمة صغيرة: ملف تنفيذي واحد، أو تثبيت pip/npm بسيط، أو أمر npx. يفضّل عدم الحاجة إلى daemon أو إعداد runtime مسبقًا.
  • بدء تشغيل سريع: يجب أن ترسل الأداة الطلب فورًا دون تسخين أو تحميل واجهة.
  • تكوين اختياري: أرسل أول طلب دون حساب أو مشروع أو ملف إعدادات.
  • مخرجات مناسبة للمحطة الطرفية: نتائج سهلة القراءة والتوجيه، مع رموز خروج مفيدة لـ CI.

إذا كان هدفك فحص نقطة نهاية يدويًا، فراجع أيضًا بدائل curl لاختبار REST API.

curl: الأساس المثبت بالفعل

غالبًا ما يكون curl مثبتًا مسبقًا على macOS ومعظم توزيعات Linux وإصدارات Windows الحديثة. لذلك، أخف تثبيت هو عدم تثبيت شيء.

# تحقق من الإصدار
curl --version

# أرسل JSON واطبع رمز حالة HTTP فقط
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'
Enter fullscreen mode Exit fullscreen mode

الأفضل لـ: الطلبات لمرة واحدة، والسكريبتات، والبيئات التي لا تسمح بتثبيت أدوات إضافية.

القيود: تضبط الرؤوس يدويًا، ولا ينسّق JSON افتراضيًا، وتحتاج إلى jq أو منطق shell لتأكيد الاستجابة. curl يرسل ويعرض؛ لكنه ليس محرك اختبارات.

HTTPie: curl للبشر

يوفر HTTPie صياغة أبسط للطلبات اليدوية. استخدم key=value للحقول النصية وkey:=value للقيم الرقمية أو JSON، مع مخرجات ملونة ومنسقة افتراضيًا.

python -m pip install httpie
# أو: brew install httpie

# age:=24 يرسل رقمًا، وname=acme يرسل نصًا
http POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

الأفضل لـ: استكشاف API يدويًا عندما تريد مخرجات مقروءة وأوامر أقل تعقيدًا.

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

xh: تجربة HTTPie في ملف تنفيذي واحد

يعيد xh تنفيذ صياغة HTTPie بلغة Rust. تحصل على أوامر مألوفة ومخرجات ملونة، لكن مع بدء أسرع وبدون runtime مثل Python.

brew install xh
# أو: cargo install xh --locked

# صياغة مشابهة لـ HTTPie مع بدء أسرع
xh POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

يمكنك أيضًا عرض أمر curl المكافئ:

xh --curl GET https://httpbin.org/get
Enter fullscreen mode Exit fullscreen mode

الأفضل لـ: من يفضل تجربة HTTPie لكن يريد ملفًا تنفيذيًا سريعًا وخفيفًا.

القيود: لا يدعم جميع ميزات HTTPie، ولا يملك نظام إضافات مماثلًا. وهو عميل HTTP، لا محرك تأكيدات.

Hurl: اختبارات نصية بسيطة تعمل في CI

ينقل Hurl العمل من «إرسال طلب» إلى «اختبار استجابة». اكتب الطلبات والتأكيدات في ملف .hurl نصي ثم شغّله في جهازك أو في CI.

brew install hurl
# أو: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

# يعيد رمز خروج غير صفري عند فشل أي تأكيد
hurl --test login.hurl
Enter fullscreen mode Exit fullscreen mode

الأفضل لـ: اختبارات العقود وSmoke tests المخزنة في التحكم بالإصدار كنص قابل للمراجعة.

القيود: يركز على HTTP، لذلك لا يشغّل gRPC ولا يولد حملًا فعليًا. التدفقات المعقدة قد تعني المزيد من ملفات .hurl بدلًا من منطق برمجي كامل.

Step CI: ملف YAML واحد لتدفق متعدد الخطوات

يتيح Step CI وصف تدفق API كامل في YAML: تسجيل دخول، التقاط token، استخدامه في طلب تالٍ، ثم التحقق من النتيجة. يدعم REST وGraphQL وgRPC وtRPC وSOAP، ويمكنه التحقق من مواصفات OpenAPI.

npm install -g stepci

# يحتوي workflow.yml على الخطوات والمتغيرات والتأكيدات
stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

الأفضل لـ: الفرق التي تحتاج إلى ملف تصريحي واحد لتدفق API متعدد الخطوات يعمل محليًا وفي CI بالطريقة نفسها.

القيود: يعتمد على Node.js، لذا فهو أثقل من أدوات Rust أو Go ذات الملف التنفيذي الواحد. تحقق من نشاط المستودع قبل اعتماده كأساس لمسار عمل طويل الأجل.

للتخطيط لمستويات الاختبار المختلفة، راجع استراتيجيات اختبار API.

k6: اختبار الحمل من المحطة الطرفية

يجيب k6 عن سؤال الأداء: هل ستصمد API تحت الحمل؟ وهو ملف تنفيذي مبني بلغة Go يستخدم JavaScript لكتابة السيناريوهات. يمكن للـ thresholds تحويل اختبار الأداء إلى نتيجة نجاح أو فشل مناسبة لـ CI.

brew install k6
# أو عبر Docker: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 10,
  duration: '30s',
  thresholds: {
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}
EOF

k6 run load.js
Enter fullscreen mode Exit fullscreen mode

الأفضل لـ: اختبارات الحمل والأداء القابلة للبرمجة والتي تريد تشغيلها في CI دون إعداد cluster.

القيود: ليس عميل اختبار وظيفي يدويًا؛ لن تستخدمه لفحص استجابة واحدة بسرعة. كما يتطلب كتابة سيناريوهات JavaScript مفيدة.

Newman: تشغيل مجموعات Postman بدون واجهة رسومية

Newman هو مشغل سطر الأوامر لمجموعات Postman. صدّر المجموعة، وصدّر البيئة عند الحاجة، ثم شغّل الاختبارات نفسها في CI.

npm install -g newman

# collection.json مُصدّر من Postman
# -e يمرر ملف البيئة
newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

الأفضل لـ: الفرق التي تستخدم Postman بالفعل وتريد تشغيل مجموعاتها الحالية من CI بدون واجهة رسومية.

القيود: يعتمد على Node.js ولا يشغّل إلا مجموعات Postman JSON. بناء الاختبارات نفسه يبقى مرتبطًا بنظام Postman البيئي.

Apidog CLI: تشغيل السيناريوهات المرئية في CI

Apidog CLI هو حزمة npm باسم apidog-cli لتشغيل سيناريوهات الاختبار التي تبنيها في واجهة Apidog من المحطة الطرفية. أنشئ التدفق المرئي، واربط الطلبات، واستخرج المتغيرات، وأضف التأكيدات؛ ثم استخدم CLI لتشغيل السيناريو بدون واجهة رسومية.

npm install -g apidog-cli

apidog login --with-token <YOUR_TOKEN>

# انسخ الأمر الدقيق من تبويب CI/CD في السيناريو
apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

لا تخمّن معرف السيناريو أو البيئة. افتح سيناريو الاختبار في Apidog، وانتقل إلى تبويب CI/CD، ثم انسخ أمر apidog run المولّد بالمعرفات الصحيحة.

استخدم -r cli للحصول على تفاصيل التنفيذ وملخصه في المحطة الطرفية. وإذا كانت منصة CI تدعم تقارير JUnit، استخدم:

apidog run -t <scenario_id> -e <env_id> -r cli,junit
Enter fullscreen mode Exit fullscreen mode

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

الأفضل لـ: الفرق التي تؤلف سيناريوهات معقدة ومتعددة الخطوات في محرر مرئي، ثم تشغلها في CI أو من وكيل بدون واجهة رسومية.

القيود: يرتبط بالسيناريوهات المحفوظة في مشروع Apidog، لذلك ليس عميل HTTP عامًا مثل curl أو xh. Apidog ليس مفتوح المصدر، لكنه يوفر طبقة استخدام مجانية مع CLI.

للمزيد، راجع الدليل الكامل لـ Apidog CLI، ومرجع أمر apidog run، ودليل اختبار REST API من سطر الأوامر باستخدام Apidog CLI.

كيف تختار

الأداة الأفضل لـ التثبيت مفتوحة المصدر؟ ملاحظات
curl طلبات لمرة واحدة وسكريبتات مثبت مسبقًا نعم شامل، والتأكيدات يدوية
HTTPie طلبات يدوية قابلة للقراءة pip install httpie نعم صياغة ودودة، يحتاج Python
xh تجربة HTTPie أسرع brew install xh نعم ملف Rust تنفيذي واحد
Hurl اختبارات HTTP نصية brew install hurl نعم --test مناسب لـ CI
Step CI تدفقات YAML متعددة الخطوات npm i -g stepci نعم REST/GraphQL/gRPC، يحتاج Node
k6 اختبار الحمل والأداء brew install k6 نعم سيناريوهات JavaScript وحدود نجاح
Newman مجموعات Postman في CI npm i -g newman نعم يشغّل Postman JSON بدون GUI
Apidog CLI سيناريوهات مرئية تُشغّل بدون GUI npm i -g apidog-cli لا يعتمد على رمز الخروج وتقارير JSON

ابدأ من الأداة الأقرب لحاجتك الحالية:

  1. استخدم curl أو xh لفحص نقطة نهاية يدويًا.
  2. انتقل إلى Hurl عندما تريد تحويل الفحص إلى اختبار نصي في التحكم بالإصدار.
  3. استخدم Step CI عند الحاجة إلى تدفق تصريحي متعدد الخطوات.
  4. استخدم k6 عندما يصبح السؤال متعلقًا بالحمل والأداء.
  5. استخدم Newman إذا كانت اختباراتك موجودة أصلًا في Postman.
  6. اختر Apidog CLI إذا أردت بناء سيناريو مرئي وتشغيله في أي بيئة بدون واجهة رسومية.

للمقارنة مع سير عمل headless كامل، راجع أدوات اختبار API بدون واجهة رسومية.

أين تؤتي الأدوات الخفيفة ثمارها؟

تفوز أدوات CLI عندما تريد البقاء في المحطة الطرفية، أو تشغيل الاختبارات في CI بدون تدخل بشري، أو تمكين وكيل AI من تشغيل الفحوصات وقراءة نتائجها.

  • يحافظ curl وxh على سرعة العمل اليدوي.
  • يحول Hurl وStep CI الطلبات إلى اختبارات قابلة للتكرار.
  • يختبر k6 الأداء تحت الحمل.
  • يشغّل Newman مجموعات Postman الحالية.
  • يربط Apidog CLI بين بناء السيناريو المرئي وتشغيله في المحطة الطرفية أو pipeline أو بواسطة وكيل.

صمّم السيناريو مرة واحدة في Apidog، ثم شغّله باستخدام apidog run حيثما تحتاج. نزّل Apidog، وابنِ سيناريو واحدًا، ثم أضف أمر التشغيل إلى إعداد CI لتجربة الدورة كاملة.

Top comments (0)