إذا كنت قد بحثت عن طريقة للحصول على اختبارات API دون كتابتها يدويًا، فمن المحتمل أن تكون قد صادفت Keploy. إنه يعد بشيء يبدو مريحًا للغاية: وجّهه نحو تطبيقك قيد التشغيل، دعه يراقب حركة المرور الحقيقية، وستخرج بمجموعة اختبار. فما الذي يفعله Keploy بالفعل تحت الغطاء، وأين يتناسب مع مكدس الاختبار الخاص بك؟
يشرح هذا الدليل ماهية Keploy، وكيف يعمل محرك التسجيل وإعادة التشغيل الخاص به على طبقة شبكة eBPF، ومهام سير العمل التي يقدمها، وكيفية تثبيته وتشغيله، والحدود الصادقة التي يجب أن تعرفها قبل اعتماده.
ما هو Keploy
Keploy عبارة عن منصة مفتوحة المصدر (مرخصة بموجب Apache-2.0) لإنشاء بيئات اختبار معزولة وآمنة للإنتاج لاختبارات API، والتكامل، والاختبار الشامل (end-to-end). الفكرة الأساسية هي أن تطبيقك الحقيقي يمارس بالفعل السلوك الذي ترغب في اختباره. فبدلاً من مطالبتك بوصف هذا السلوك في كود الاختبار، يراقبه Keploy ويحوله إلى اختبارات قابلة لإعادة الإنتاج.
يوفر لك طريقتين للقيام بذلك:
- التسجيل وإعادة التشغيل يلتقط تفاعلات API الحقيقية وتوابعها، ثم يعيد تشغيلها بشكل حتمي.
- توليد الاختبارات بواسطة الذكاء الاصطناعي يبني مجموعات اختبار API مُصدقة من مواصفة، أو مجموعة، أو أمر cURL، أو نقطة نهاية حية.
كلاهما ينتج اختبارات قابلة للتشغيل بالإضافة إلى المحاكاة (mocks) اللازمة لتشغيلها دون الحاجة إلى توابع حية. المشروع مفتوح المصدر، لذا يمكنك قراءة الكود واستضافته ذاتيًا. يوجد المستودع على github.com/keploy/keploy، والوثائق الرسمية على keploy.io/docs.
كيف يعمل تسجيل Keploy على طبقة eBPF
هذا هو الجزء الذي يجعل Keploy متميزًا. عندما تقوم بتشغيل keploy record، فإنه لا يطلب منك إضافة SDK أو تغيير سطر واحد من كود تطبيقك. يلتقط حركة المرور على طبقة الشبكة باستخدام eBPF، وهي تقنية نواة Linux تتيح للبرامج مراقبة أحداث النظام والتصرف بناءً عليها بأمان.
إليك ما يوفره لك ذلك عمليًا:
- التقاط بدون كود. لا توجد أدوات قياس، ولا أطر اختبار، ولا مزينات في معالجاتك. يجلس Keploy أسفل تطبيقك ويراقب البايتات الداخلة والخارجة.
- التقاط مستقل عن اللغة. نظرًا لأن الالتقاط يحدث على طبقة شبكة النواة بدلاً من داخل وقت التشغيل، فإنه يعمل بنفس الطريقة سواء كانت خدمتك مكتوبة بلغة Go أو Python أو Rust.
- التقاط التوابع. لا يسجل Keploy فقط استدعاء API الوارد واستجابته. بل يسجل أيضًا الاستدعاءات الصادرة التي يقوم بها خدمتك إلى توابعها، مثل استعلامات قاعدة البيانات وأحداث الشبكة أو البث.
تلك النقطة الأخيرة مهمة. عندما يسجل Keploy طلبًا، فإنه يلتقط الصورة الكاملة: طلب API، واستجابة API، وكل استدعاء تابع حدث بينهما. ثم يكتب ناتجين من هذا التفاعل الواحد الذي تم رصده:
- حالة اختبار تصف الطلب والاستجابة المتوقعين.
- محاكاة (Mocks) و Stubs لكل استدعاء تابع، بحيث يمكن للاختبار إعادة التشغيل دون الحاجة إلى قاعدة بيانات حية أو خدمة لاحقة.
إعادة التشغيل تغلق الحلقة. عندما تقوم بتشغيل keploy test، فإنه يرسل الطلبات المسجلة مرة أخرى إلى تطبيقك، ويقدم استجابات التوابع الملتقطة من المحاكاة (mocks) التي تم إنشاؤها، ويقارن الاستجابات الجديدة بتلك المسجلة. عدم التطابق يعني أن شيئًا ما قد تغير. لهذا السبب يسمى هذا النهج التسجيل وإعادة التشغيل: تسجل سلوك وقت التشغيل الحقيقي مرة واحدة، ثم تعيد تشغيله بشكل حتمي كاختبار تراجعي عند كل تغيير.
مهام سير عمل Keploy
التسجيل وإعادة التشغيل
استخدم هذا عندما يكون لديك بالفعل تطبيق عامل وترغب في تغطية تراجعية سريعة. تقوم بتشغيل التطبيق تحت Keploy، وتختبره بالطريقة التي سيفعلها مستخدم أو عميل حقيقي (استدعاءات يدوية، اختبار تكامل موجود، أو حركة مرور حية)، ويقوم Keploy بحفظ كل تفاعل كاختبار بالإضافة إلى محاكياته. عمليات التشغيل اللاحقة تعيد تشغيل هذه التفاعلات وتُعلم عن أي انحراف في السلوك.
توليد الاختبارات بالذكاء الاصطناعي
استخدم هذا عندما تريد تغطية أوسع مما أنتجه اختبارك اليدوي، أو عندما تبدأ من عقد بدلاً من تدفق تشغيل. يمكن لـ Keploy توليد مجموعات اختبار API مُصدقة من مواصفة OpenAPI، أو مجموعة Postman، أو أمر cURL، أو نقطة نهاية حية. يقوم بمحاكاة التوابع تلقائيًا ويُجري عملية تنظيف تلقائية حتى لا تُترك بحالات زائدة عن الحاجة.
مهام سير العمل الاثنتان متكاملتان. التسجيل وإعادة التشغيل يرسخان الاختبارات في السلوك الحقيقي المرصود؛ توليد الاختبارات بالذكاء الاصطناعي يملأ الفجوات من مواصفاتك. إذا كنت تقوم بتقييم أدوات توليد الاختبارات من مخطط، فإن ملخصنا عن مولدات حالات الاختبار بالذكاء الاصطناعي ودليل توليد نصوص الاختبار من OpenAPI يُعدان رفيقين جيدين.
تثبيت Keploy
Keploy يأتي مع نص برمجي للتثبيت. على نظام مدعوم، تقوم بتشغيل:
curl --silent -O -L https://keploy.io/install.sh && source install.sh
يقوم ذلك بجلب الملف التنفيذي وإعداد أمر keploy. من هناك، يمكنك إدارة كل شيء من خلال أمرين.
أوامر Keploy الأساسية
هناك أمران ستستخدمهما غالبًا. الأول يسجل:
keploy record -c "CMD_TO_RUN_APP"
تمرر الأمر الدقيق الذي يبدأ تطبيقك عبر -c. يقوم Keploy بتشغيل تطبيقك، ويراقب حركة المرور أثناء اختباره، ويحفظ حالات الاختبار والمحاكاة الملتقطة.
الثاني يعيد التشغيل:
keploy test -c "CMD_TO_RUN_APP" --delay 10
العلامة --delay 10 تخبر Keploy بالانتظار عشر ثوانٍ قبل أن يبدأ في إرسال الطلبات المسجلة، مما يمنح الخدمة الأبطأ وقتًا كافيًا لإنهاء الإقلاع قبل بدء إعادة التشغيل. إذا كان تطبيقك يحتاج وقتًا أطول للبدء، قم بزيادة الرقم؛ إذا كان يبدأ بسرعة، يمكنك خفضه.
تبدو الجلسة الأولى النموذجية كالتالي:
# 1. سجل بينما تقوم باستدعاء API الخاص بك
keploy record -c "node server.js"
# 2. أعد تشغيل الحالات الملتقطة وتحقق من الانحراف
keploy test -c "node server.js" --delay 10
هذه هي الدورة الكاملة. سجل مرة واحدة مقابل بناء معروف جيد، ثم قم بتشغيل keploy test في CI عند كل تغيير.
اللغات والبروتوكولات ومخازن البيانات المدعومة
نظرًا لأن الالتقاط يحدث على طبقة الشبكة، يغطي Keploy نطاقًا واسعًا:
| الفئة | مدعوم |
|---|---|
| اللغات | Go, Java, Node.js, Python, Rust, C#, C/C++, TypeScript، والمزيد |
| البروتوكولات | HTTP/REST, gRPC, GraphQL, Kafka, RabbitMQ |
| مخازن البيانات | PostgreSQL, MySQL, MongoDB, Redis |
هذا النطاق الواسع هو نتيجة مباشرة لتصميم eBPF. يقرأ Keploy محادثات الشبكة، لذا لا تحتاج لغة أو إطار عمل جديد إلى مكون إضافي جديد طالما أنها تتحدث أحد هذه البروتوكولات.
تشغيل Keploy في CI
كلا الأمرين مصممان للأتمتة. في مسار (pipeline)، تلتزم بحالات الاختبار المسجلة والمحاكاة جنبًا إلى جنب مع الكود الخاص بك، ثم تقوم بتشغيل keploy test -c "..." كخطوة. نظرًا لأن المحاكاة تحل محل التوابع الحقيقية، فإن إعادة التشغيل لا تحتاج إلى قاعدة بيانات حية أو خدمة لاحقة في مشغل CI، مما يحافظ على سرعة المهمة وحتميتها. فشل إعادة التشغيل يؤدي إلى فشل البناء، بنفس الطريقة التي يفشل بها اختبار الوحدة.
قيود صريحة يجب مراعاتها
Keploy قوي فيما يفعله، ولكنه لا يناسب كل موقف. التقييم العادل يشمل المقايضات:
- يميل نحو Linux والصلاحيات المرتفعة. eBPF هي ميزة في نواة Linux، والتقاط البيانات على تلك الطبقة يتطلب عادةً أذونات مرتفعة. وهذا يحدد أين وكيف يمكنك تشغيله.
- الاختبارات المولّدة تحتاج إلى تنظيم. الاختبارات المبنية من حركة مرور حقيقية أو المولّدة بالذكاء الاصطناعي هي نقطة بداية وليست مجموعة مكتملة. لا يزال يتعين عليك مراجعتها، وإزالة الضوضاء، وتحديد السلوكيات الملتقطة التي تستحق بالفعل فرضها كعقود.
- إنه أداة للاختبار وتوليد الاختبارات، وليس منصة كاملة لدورة حياة API. يركز Keploy على التقاط الاختبارات وتوليدها وإعادة تشغيلها. لم يتم تصميمه للتعامل مع تصميم API، أو التوثيق، أو نشر خادم المحاكاة للمستهلكين، أو تعاون الفريق حول مواصفات API.
لا شيء من هذه النقاط يعد عيبًا في Keploy. إنها الحدود الطبيعية لفئته. معرفتها تساعدك على تحديد ما إذا كانت تحل مشكلتك أو جزءًا منها فقط.
أين يتناسب Apidog كبديل للاختبار المخطط له
إذا كانت حاجتك أوسع من "تحويل حركة المرور المرصودة إلى اختبارات تراجعية"، فمن الجدير بالنظر إلى منصة دورة حياة كاملة. Apidog هي منصة API شاملة تغطي التصميم، التصحيح، المحاكاة، التوثيق، والاختبار في مكان واحد. الفرق في الفلسفة هو الشيء الأساسي الذي يجب فهمه، لأن Apidog و Keploy يقعان في فئات مختلفة.
يلتقط Keploy ويعيد تشغيل سلوك وقت التشغيل الحقيقي، بما في ذلك محاكاة التوابع، بدون أي كود. يتخذ Apidog مسارًا معاكسًا: تقوم بتصميم وتأليف سيناريوهات اختبار قابلة للصيانة، ثم تشغلها من الطرفية و CI باستخدام واجهة سطر الأوامر (CLI) لـ Apidog. تشغل واجهة سطر الأوامر مجموعاتك المؤلفة باستخدام الاختبار المعتمد على البيانات عبر CSV أو JSON، وتبديل البيئات، وتقارير CLI و HTML و JSON. يقدم Apidog أيضًا توليد حالات الاختبار بواسطة الذكاء الاصطناعي من مخطط API ونقاط النهاية الخاصة بك، والتي يتم تأليفها داخل التطبيق، وهذا هو المكان الذي تتداخل فيه الأداتان.
لتوضيح الحدود: لا يلتقط Apidog حركة المرور الحية عبر eBPF، ولا يقوم بتوليد الاختبارات تلقائيًا عن طريق تسجيل استدعاءات الإنتاج بالإضافة إلى محاكاة التوابع. هذه القدرة على التسجيل من حركة المرور الحقيقية هي لـ Keploy حقًا. الإطار الصادق هو أنك تختار بناءً على المهمة. استخدم Keploy عندما تريد التقاط وتشغيل وقت التشغيل بدون أي كود. استخدم Apidog عندما تريد مجموعات اختبار مصممة وقابلة للصيانة داخل منصة تتعامل أيضًا مع بقية دورة حياة API. لمقارنة أعمق جنبًا إلى جنب، راجع Apidog مقابل Keploy، وإذا قررت التبديل، فإن شرح عملية الترحيل يغطي نقل اختباراتك.
إذا كانت اختبارات API القابلة للصيانة والمؤلفة هي ما تبحث عنه، يمكنك تنزيل Apidog والبدء بدليل اختبار API باستخدام Apidog.
الأسئلة الشائعة
هل Keploy مجاني ومفتوح المصدر؟ نعم. Keploy مفتوح المصدر بموجب ترخيص Apache-2.0، والكود موجود على GitHub. يمكنك استضافته ذاتيًا.
هل يتطلب Keploy تغيير كود تطبيقي؟ لا. يلتقط سير عمل التسجيل وإعادة التشغيل حركة المرور على طبقة شبكة eBPF، لذلك لا توجد SDK لإضافتها ولا تغييرات في الكود. وهذا أيضًا هو السبب في أنه يعمل عبر العديد من اللغات.
ماذا تفعل العلامة --delay في keploy test؟ إنها تحدد عدد الثواني التي ينتظرها Keploy قبل إرسال الطلبات المسجلة، مما يمنح تطبيقك وقتًا للإقلاع. --delay 10 ينتظر عشر ثوانٍ؛ ارفعها للخدمات بطيئة البدء.
هل يمكن لـ Keploy محاكاة قاعدة بياناتي أثناء الاختبارات؟ نعم. عندما يسجل تفاعلًا، فإنه يلتقط أيضًا استدعاءات التوابع (مثل استعلامات قاعدة البيانات) ويكتب محاكاة لها، بحيث تعمل عمليات إعادة التشغيل بدون قاعدة بيانات حية.
هل Keploy بديل لأداة تصميم وتوثيق API؟ لا. Keploy هو أداة للاختبار وتوليد الاختبارات. لتصميم API، والتوثيق، والمحاكاة للمستهلكين، والتعاون جنبًا إلى جنب مع الاختبار، تعد منصة دورة حياة كاملة مثل Apidog هي الأنسب.
النسخة المختصرة
Keploy هي أداة مفتوحة المصدر تحول سلوك API الحقيقي إلى اختبارات. يستخدم محرك التسجيل وإعادة التشغيل الخاص بها eBPF لالتقاط الطلبات والاستجابات واستدعاءات التوابع على طبقة الشبكة دون تغييرات في الكود، ثم يعيد تشغيلها كاختبارات تراجعية حتمية. يبني توليد الاختبارات بالذكاء الاصطناعي مجموعات من مواصفة أو نقطة نهاية. إنه سريع التبني ومستقل عن اللغة، مع مقايضات نموذج التقاط يميل إلى Linux، واختبارات تحتاج إلى مراجعة، ونطاق يقتصر على الاختبار. إذا كنت تريد مجموعات اختبار مؤلفة وقابلة للصيانة داخل منصة API كاملة، فإن Apidog هو البديل للمقارنة به.