ما الذي ما زال SoapUI يجيده
SOAP وWSDL. دعم من الدرجة الأولى فعلًا، في حين تتعامل معه معظم الأدوات الحديثة كأمر ثانوي، إن تعاملت معه أصلًا.
بناء الرسائل المعقّدة. معالجة عميقة لـ XML وتحقّق دقيق منه، وهو تحديدًا ما يحتاجه التكامل المؤسسي.
الخدمات الوهمية. إنشاء نقطة نهاية صورية تطوّر مقابلها، مدمج في الأداة.
إن كان عملك يعتمد بكثافة على SOAP، فانتبه لما ستتخلى عنه. فاتساع التغطية هنا حقيقي.
لماذا تبحث الفرق رغم ذلك
| سير عمل مصمَّم لسطح المكتب | ملفات مشروع تقيم على جهاز أحدهم ويصعب مراجعتها. ونسب التغييرات إلى أصحابها داخل طلب سحب أمر عسير. |
| احتكاك مع خط التسليم | التنفيذ بلا واجهة ممكن، ونادرًا ما يكون مريحًا. والتقارير لا تصل إلى حيث تصل بقية تقارير CI. |
| سهولة التعامل مع REST | بُني النموذج من أجل SOAP. أما REST فيعمل ويبدو دخيلًا. |
على أي أساس تقارن بديل SoapUI
| المعيار | SoapUI | TestSprite |
|---|---|---|
| نطاق البروتوكولات | SOAP وWSDL وREST وJMS وغيرها | واجهات REST API مقابل الخدمة العاملة |
| أين تقيم الاختبارات | ملفات مشروع تُحرَّر في عميل على سطح المكتب | داخل المشروع، موصوفة بلغة عادية |
| كيف تُبنى التغطية | شخص يبني كل طلب وكل تحقّق | تُولَّد من مواصفة أو من جولة اكتشاف |
| الجلسة والحالة | خصائص وبرامج نصية تتولى صيانتها | Auto-Authentication وDynamic Variables |
| الترتيب والتنظيف | ترتيب حالات الاختبار إضافة إلى نصوص التفكيك | ترتيب مُستنتَج وAuto-Cleanup |
| الملاءمة لخط التسليم | مشغّل بلا واجهة، وتقارير منفصلة | يُشغَّل بالتغيير، والنتائج على طلب السحب |
تفاصيل آلية التعامل مع الحالة موجودة في توثيق اختبار API.
التحقق قبل الانتقال
احصر ما هو SOAP فعلًا. كثيرًا ما تكتشف الفرق أن تسعين بالمئة من الحزمة هو REST، مع حفنة من نقاط نهاية SOAP القديمة لم يمسّها أحد منذ سنوات. وإن كان هذا حالك، فالترحيل أصغر بكثير مما يبدو، ويمكن لما تبقى من SOAP أن يبقى مكانه.
وإن كانت تعتمد على SOAP بكثافة حقيقية، فلا تنتقل من أجل سهولة التعامل. فاتساع التغطية أهم.
كيف تقيّم أيًّا منها
اكسر شيئًا عن عمد. أدخِل انحدارًا حقيقيًا، كعملية حفظ لم تعد تثبت، وراقب ما يبلّغ عنه كل مرشّح. هل يفشل؟ وهل يسمّي الفشلُ الانحرافَ الفعلي؟ وهل يستطيع من سيصلحه أن ينطلق من ذلك المخرج دون أن يعيد استنتاج القصة من جديد؟ الأداة التي تبلّغ بنجاح تشغيل لم يبلغ أصلًا تحقّقاته تكون قد رسبت في الاختبار الوحيد المهم.
تقسيم الحزمة قبل الانتقال
الترحيل الناجح لا يتم دفعة واحدة إلا نادرًا، والتقسيم أسهل مما يبدو لأن SOAP وREST قلّما يتشابكان داخل الاختبار نفسه.
ابدأ بوسم كل حالة اختبار بحسب البروتوكول. تجد معظم الفرق ثلاث مجموعات: SOAP حقيقي مقابل خدمات قديمة، وREST مقابل خدمات أحدث، وحفنة تمسّ الاثنين لأن سير عمل واحدًا يمتد عبر جيلين. المجموعة الأولى تبقى مكانها وتكفّ عن كونها سببًا لإبقاء الحزمة كلها هناك. والثانية تنتقل. أما الثالثة فتستحق النظر فيها حالة بحالة، وكثيرًا ما تنقسم إلى اختبارين كانا قد دُمجا للتيسير لا للضرورة.
والبدء بالوسم يعني أن للترحيل نهاية مرئية، وهذا هو الفرق بين مشروع ينتهي وآخر يبقى نصف منجز بعد عام.
البداية
الطرفية
npm install -g @testsprite/testsprite-cli
testsprite setup
وإن كنت تفضّل ألا تثبّت شيئًا، فلوحة التحكم تؤدي الغرض نفسه. وكل ما يستطيع سطر الأوامر فعله غير ذلك موجود في مستودع CLI.
GitHub App هو خطاف ويب تُعدّه من لوحة تحكم TestSprite. يستمع إلى حدث النشر الذي ينتجه خط التسليم لديك أصلًا، فلا يتغير شيء في مستودعك.
GitHub Actions يضع الخطوة داخل سير عملك أنت، ويُهيَّأ من الطرفية.
ما الذي يغطيه TestSprite في جانب REST
كل ما كان يقوم به جزء REST من حزمتك، مع سير عمل مفصَّل على مقاس خط التسليم لا سطح المكتب. الحالات تقيم داخل المشروع، وتُوصف بلغة عادية، وتُنقَّح بالطريقة نفسها، فيصبح التغيير شيئًا يستطيع شخص ثانٍ مراجعته.
ويأتي التعامل مع الحالة كجزء من المنتج: Auto-Authentication وDynamic Variables وDependency Chains وAuto-Cleanup، وهي في SoapUI خصائص وخطوات نقل وترتيب حالات اختبار ونصوص تفكيك تتولى صيانتها بنفسك.
تنطلق عمليات التشغيل بنشرك أو من سير عملك، وتصل النتائج كتعليق على طلب السحب. فيبقى عملك على SOAP حيث يُدعم كما ينبغي، ويكون للترحيل نهاية مرئية بدل أن يظل نصف منجز بعد عام.
هل يدعم TestSprite بروتوكول SOAP؟
التركيز على واجهات REST API مقابل خدمة عاملة. أما الحزم التي تعتمد بكثافة على SOAP، فأبقِ ما يتعامل مع SOAP كما ينبغي واستخدم هذا لنطاق REST.
هل يمكننا تحويل مشاريع SoapUI؟
استخدمها كجرد لما هو موجود، لا كشيء يُحوَّل. فقائمة نقاط النهاية والتحقّقات التي اهتم بها الناس هي المحتوى القيّم.
وماذا عن الخدمات الوهمية؟
قدرة منفصلة تستحق الإبقاء إن كنت تعتمد عليها. فالمحاكاة والتحقق مهمتان مختلفتان.
هل تستحق نسخة Pro العناء بدل الانتقال؟
إن كانت الشكوى تتعلق بالميزات، فربما. أما إن كانت الشكوى أن سير العمل لا يلائم خط التسليم، فمستوى الترخيص لن يغيّر ذلك.
كيف نشغّل الاثنين معًا خلال فترة الانتقال؟
وجّه كلًّا منهما إلى جزء مختلف من النطاق وشغّلهما معًا من CI. لا داعي للتحول دفعة واحدة.
تحقق من حجم ما هو SOAP فعلًا في حزمتك.
يصبح بديل SoapUI منطقيًا حين يتوقف سير العمل المصمَّم لسطح المكتب عن ملاءمة خط التسليم لديك، وتتبين معظم الحزم في النهاية أنها REST في أغلبها. أبقِ SoapUI لعمل SOAP الحقيقي، وانقل نطاق REST إلى مكان يلائم طريقتك في الإصدار.