إذا بدأ فريقك باستخدام Keploy، فمن المحتمل أن السبب واضح: تشغّل التطبيق، تضرب بعض نقاط النهاية، ثم تظهر الاختبارات تلقائيًا. لا تكتب التأكيدات يدويًا، ولا تهيّئ التبعيات واحدة تلو الأخرى. يلتقط Keploy حركة المرور الحقيقية على طبقة الشبكة ويعيد تشغيلها لك.
لكن الانتقال من Keploy إلى Apidog يصبح منطقيًا عندما تحتاج إلى اختبارات يمكن قراءتها ومراجعتها وتعديلها داخل الفريق. الاختبارات الملتقطة ممتازة لاكتشاف التراجعات في سلوك حدث بالفعل، لكنها ليست دائمًا سهلة الامتلاك داخل Pull Requests. في Apidog، تبني سيناريوهات واضحة، تتحكم في بيانات الاختبار، تبدّل البيئات صراحة، وتصمم الخوادم الوهمية بدل الاعتماد على تسجيل سابق.
نموذجان مختلفان، مقارنة صريحة
تتداخل Keploy وApidog في مصطلح "اختبار واجهة برمجة التطبيقات"، لكنهما يعالجان المشكلة من زاويتين مختلفتين.
Keploy منصة مفتوحة المصدر لإنشاء بيئات اختبار معزولة. قوتها الأساسية هي التسجيل وإعادة التشغيل: باستخدام eBPF على طبقة الشبكة، تلتقط مكالمات API الحقيقية وتبعياتها مثل استعلامات قواعد البيانات والخدمات الخلفية وأحداث البث، دون SDK أو تغييرات في الكود. من هذه الحركة، تولّد حالات اختبار ووحدات محاكاة تلقائيًا. كما تدعم توليد اختبارات بالذكاء الاصطناعي من OpenAPI أو Postman أو cURL أو نقطة نهاية حية. لأن الالتقاط يتم عبر eBPF، فهو مستقل عن اللغة، لكنه يعتمد على Linux وصلاحيات مرتفعة. الكود متاح على GitHub.
Apidog منصة API متكاملة للتصميم، وتصحيح الأخطاء، والمحاكاة، والتوثيق، والاختبار. يستخدم Apidog CLI الأمر apidog run لتشغيل السيناريوهات والمجموعات التي أنشأتها من الطرفية أو داخل CI/CD. يدعم الاختبار الموجه بالبيانات، وتبديل البيئات، وتنسيقات تقارير متعددة، وتقارير سحابية. كما يدعم توليد حالات الاختبار بالذكاء الاصطناعي من مخطط API ونقاط النهاية داخل التطبيق، وليس من تسجيل حركة مرور الإنتاج.
النقطة المهمة: لا يلتقط Apidog حركة المرور الحية عبر eBPF، ولا يولّد اختبارات تلقائيًا من مكالمات الإنتاج مع محاكاة التبعيات. هذه هي قوة Keploy. إذا كان تسجيل وقت التشغيل هو جوهر سير عملك، فاحتفظ بـ Keploy لهذه المهمة. أما ما تكسبه من Apidog فهو اختبارات مصممة، قابلة للمراجعة، مشتركة بين الفرق، ومرتبطة بدورة حياة API كاملة.
| نهج Keploy | نهج Apidog |
|---|---|
keploy record يلتقط حركة المرور الحقيقية عبر eBPF |
استيراد سطح API كـ OpenAPI أو Postman أو cURL |
| اختبارات تُولَّد تلقائيًا من المكالمات الملتقطة | توليد حالات اختبار بالذكاء الاصطناعي من المواصفات، مع سيناريوهات تؤلفها يدويًا |
keploy test --delay 10 يعيد تشغيل التسجيلات |
apidog run ينفذ السيناريوهات داخل CI |
| محاكاة التبعيات من حركة مرور قاعدة البيانات/الشبكة | خوادم وهمية تصممها وتتحكم فيها |
| بيانات الاختبار مدمجة في التسجيل | اختبار موجه بالبيانات عبر -d باستخدام CSV/JSON |
| البيئة ضمنية من التشغيل المسجل | بيئات صريحة يتم تبديلها عبر -e
|
| يتطلب Linux/eBPF وصلاحيات مرتفعة | يعمل حيث يعمل CLI، بما في ذلك أدوات CI القياسية |
اقرأ الجدول كخريطة انتقال. في Keploy، "الأداة اكتشفت ذلك من حركة المرور". في Apidog، "أنت تصف السلوك الصحيح وتجعله قابلًا للمراجعة".
الخطوة 1: حوّل سطح API إلى مواصفات
Keploy يبدأ من تطبيق قيد التشغيل. Apidog يبدأ من وصف منظم لـ API. لذلك أول خطوة هي توفير هذا الوصف.
إذا كان لديك ملف OpenAPI جاهز، استخدمه مباشرة. إذا لم يكن لديك، اختر أحد المسارات التالية:
- ولّد OpenAPI من إطار العمل الذي تستخدمه.
- صدّر مجموعة Postman الموجودة لدى الفريق.
- اجمع أوامر cURL الأساسية لكل نقطة نهاية.
إذا كان لديك تسجيلات Keploy، استخدمها كقائمة تحقق: ما نقاط النهاية التي استُدعيت فعليًا؟ ما الحمولات المستخدمة؟ ما الحالات التي ظهرت؟ لا تستورد التسجيلات نفسها إلى Apidog، لكن استفد منها لضمان أن المواصفات تغطي السلوك الحقيقي.
الخطوة 2: استورد المشروع إلى Apidog
نزّل Apidog، أنشئ مشروعًا، ثم استورد OpenAPI أو Postman أو cURL. بعد الاستيراد، سيملأ Apidog نقاط النهاية، مخططات الطلب، المعاملات، ونماذج الاستجابة.
النتيجة ليست مجرد تجهيزات اختبار. نفس التعريف يصبح:
- وثائق API قابلة للمشاركة.
- طلبات يمكن تصحيحها يدويًا.
- أساسًا للخوادم الوهمية.
- مصدرًا لسيناريوهات الاختبار.
لشرح كامل لسير العمل عبر CLI، راجع الدليل الكامل لـ Apidog CLI.
الخطوة 3: ولّد مسودة اختبارات، ثم اكتب السيناريوهات المهمة
هنا تستعيد جزءًا من سرعة Keploy. يمكن لـ توليد حالات الاختبار بالذكاء الاصطناعي في Apidog قراءة المخطط ونقاط النهاية المستوردة، ثم اقتراح حالات مثل:
- طلبات صالحة.
- قيم حدودية.
- حالات فشل شائعة.
- استجابات متوقعة بناءً على المواصفات.
تعامل مع الناتج كمسودة، لا كاختبار نهائي. راجع الحالات، احذف غير المفيد، وشدد التأكيدات. هذا ينطبق على أي توليد بالذكاء الاصطناعي، سواء في Apidog أو Keploy.
بعد ذلك، اكتب السيناريوهات التي تمثل تدفقات حقيقية. مثال عملي:
- إنشاء مستخدم.
- تسجيل الدخول.
- حفظ الرمز المميز من الاستجابة.
- جلب الملف الشخصي.
- تحديث البيانات.
- حذف المستخدم.
- التأكد من أن الجلب اللاحق يعيد خطأ مناسبًا.
في Keploy، هذا التدفق يكون ضمنيًا داخل التسجيل. في Apidog، تجعله صريحًا ومقروءًا. هذا يتطلب وقتًا في البداية، لكنه يجعل الاختبار أسهل في المراجعة والتعديل لاحقًا.
للموازنة بين التوليد الآلي والتأليف اليدوي، راجع كيفية كتابة حالات الاختبار بمساعدة الذكاء الاصطناعي، ويمكنك أيضًا الاطلاع على مقارنة أفضل مولدات حالات الاختبار بالذكاء الاصطناعي.
الخطوة 4: عرّف البيئات وبيانات الاختبار
تسجيل Keploy يحمل قيمًا من تشغيل واحد. في Apidog، اجعل الاختبار قابلاً للتشغيل على أكثر من بيئة وأكثر من مجموعة بيانات.
عرّف البيئات مثل:
localstagingproduction
لكل بيئة، اضبط:
- Base URL
- الرموز المميزة
- المتغيرات السرية أو العامة
- أي إعدادات خاصة بالخدمة
عند التشغيل، اختر البيئة باستخدام -e.
أما بيانات الاختبار، فاحتفظ بها في CSV أو JSON، ثم مررها باستخدام -d. بهذه الطريقة، يمكن لسيناريو تسجيل دخول واحد أن يعمل على عدة مستخدمين أو حالات.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
مثال CSV بسيط:
email,password,expectedStatus
user1@example.com,correct-password,200
user2@example.com,wrong-password,401
locked@example.com,password,403
الميزة هنا أن بيانات الاختبار أصبحت ملفًا يمكن مراجعته في Pull Request وتوسيعه مع ظهور حالات جديدة. للتفاصيل حول التنسيقات وربط المتغيرات، راجع دليل الاختبار الموجه بالبيانات.
الخطوة 5: شغّل الاختبارات في CI باستخدام apidog run
الأمر الذي يحل محل keploy test في خط الأنابيب هو:
apidog run
يشغّل هذا الأمر السيناريوهات التي كتبتها، يطبق البيئة المحددة، يستخدم بيانات الاختبار، ثم يخرج بتقارير. يمكنك إنشاء تقارير CLI وHTML وJSON، ورفع التقرير إلى السحابة باستخدام --upload-report.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
في CI، اجعل الخطوة بسيطة:
- ثبّت Apidog CLI.
- مرر
APIDOG_ACCESS_TOKENكـ secret. - مرر معرف السيناريو أو المجموعة.
- اجعل البناء يفشل إذا خرج الأمر بقيمة غير صفرية.
مثال عام:
- name: Run Apidog tests
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r cli,json \
--upload-report
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
راجع دليل خط أنابيب CI/CD، وشرح GitHub Actions، ودليل تقارير الاختبار لتفاصيل أكثر.
الخطوة 6: ابنِ خوادم وهمية تتحكم فيها
Keploy ينشئ المحاكاة من حركة التبعيات أثناء التسجيل. Apidog يتخذ مسارًا مختلفًا: أنت تصمم المحاكاة من المخطط.
بما أنك استوردت OpenAPI أو Postman، يمكن لـ Apidog إنشاء خادم وهمي يعيد استجابات مبنية على المخطط والأمثلة والقواعد التي تحددها. يمكنك ضبط:
- الحمولات الدقيقة.
- حالات النجاح والفشل.
- رموز الحالة.
- زمن الاستجابة.
- استجابات مختلفة حسب المدخلات.
المقايضة واضحة: المحاكاة الملتقطة تعكس ما فعلته التبعيات فعليًا، أما المحاكاة المصممة فتعكس العقد الذي تريد اختباره. لاختبار العقود وCI المستقر، غالبًا تكون المحاكاة المصممة أسهل في الصيانة لأنها لا تتغير مع بيئة الإنتاج.
للمزيد، راجع أدوات اختبار العقود والمحاكاة وتوليد بيانات وهمية من مخططات OpenAPI.
ما تحتفظ به وما تتخلى عنه
كن واضحًا مع الفريق قبل الانتقال.
تتخلى عن:
- الالتقاط التلقائي عبر
keploy record. - محاكاة التبعيات المشتقة من تشغيلات حقيقية.
- سحر eBPF الذي يعمل دون تعديل الكود.
- تسجيل سلوك الإنتاج كما هو وإعادة تشغيله.
وتكسب:
- اختبارات يمكن قراءتها كتوثيق.
- سيناريوهات قابلة للمراجعة في Pull Requests.
- بيئات صريحة عبر
-e. - بيانات اختبار تملكها عبر CSV/JSON.
- خوادم وهمية مصممة ومستقرة.
- منصة واحدة للتصميم، التصحيح، التوثيق، المحاكاة، والاختبار.
إذا كانت حاجتك الأساسية هي التقاط سلوك وقت التشغيل الحقيقي، احتفظ بـ Keploy. إذا كانت حاجتك الأساسية هي قابلية الصيانة والتعاون عبر الفريق، انتقل تدريجيًا إلى Apidog أو شغّل الأداتين معًا.
لرؤية الصورة الأوسع، راجع أدوات أتمتة اختبار API وكيفية اختبار API باستخدام Apidog. وإذا كنت تقارن مباشرة، اقرأ مقارنة Apidog مقابل Keploy وأفضل بدائل Keploy.
أسئلة متكررة
هل يمكن لـ Apidog استيراد تسجيلات Keploy الموجودة لدي؟
ليس بشكل مباشر. تسجيلات Keploy هي لقطات وقت تشغيل، بينما يعمل Apidog من مواصفات API. المسار العملي هو إنشاء OpenAPI أو Postman أو cURL، ثم استيرادها إلى Apidog. استخدم تسجيلات Keploy كقائمة تحقق للتغطية.
هل يسجل Apidog حركة المرور الحية ويقوم بمحاكاة قاعدة البيانات تلقائيًا مثل Keploy؟
لا. لا يلتقط Apidog الحركة عبر eBPF ولا يولّد محاكاة التبعيات تلقائيًا من تشغيلات حقيقية. هذه هي قوة Keploy. Apidog يولّد الاختبارات والمحاكاة من المخطط، ثم تؤلف أنت السيناريوهات.
ما الذي يحل محل keploy record وkeploy test؟
لا يوجد بديل مباشر لـ keploy record. بدلًا من ذلك، تستورد مواصفات API، تولّد مسودة اختبارات، تكتب السيناريوهات، ثم تشغّلها باستخدام apidog run بدل keploy test.
هل يستحق الانتقال جهد التأليف الإضافي؟
نعم، إذا كنت تريد اختبارات قابلة للقراءة والمراجعة وملكية مشتركة داخل الفريق. لا، إذا كانت أولويتك هي تسجيل سلوك وقت التشغيل الحقيقي بأقل جهد ممكن. في هذه الحالة، Keploy ما زال مناسبًا لتلك المهمة.
هل يمكن تشغيل Keploy وApidog معًا؟
نعم. يمكن استخدام Keploy لفحوصات الانحدار القائمة على الالتقاط، واستخدام Apidog للسيناريوهات المصممة، والوثائق، والمحاكاة، وCI. الأداتان تحلان مشكلات مختلفة.
من أين تبدأ
ابدأ بخدمة واحدة فقط:
- صدّر OpenAPI أو Postman أو cURL.
- استوردها إلى Apidog.
- ولّد مسودة اختبارات بالذكاء الاصطناعي.
- اكتب سيناريو حقيقيًا واحدًا.
- أضف بيئة
staging. - أضف ملف بيانات صغيرًا.
- شغّل:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv \
-r cli,html
- اربطه بـ CI.
- وسّع التغطية تدريجيًا.
ستتخلى عن راحة التسجيل التلقائي، لكنك ستحصل على اختبارات يستطيع الفريق قراءتها وتغييرها والثقة بها. للتعمق في CLI، ابدأ بـ دليل التثبيت واختبار REST API عبر سطر الأوامر.



Top comments (0)