مرحبا بالجميع. نحن نخرج ببطء من الظل ونواصل سلسلة من المقالات حول منتجاتنا. بعد مقالة المراجعة السابقة ، تلقينا الكثير من المراجعات (معظمها إيجابية) والاقتراحات وتقارير الأخطاء. اليوم سوف نعرض TestMace في العمل ، وسوف تكون قادرا على تقدير بعض ميزات تطبيقنا. للحصول على مزيد من الغوص ، أنصحك بالرجوع إلى الوثائق الخاصة بنا على http://docs-ru.testmace.com . لذلك دعونا نذهب!

تركيب

دعنا نبدأ مع العاديه. يمكن الوصول إلى التطبيق واختباره بالفعل على ثلاث منصات - Linux و Windows و MacOS. يمكنك تنزيل برنامج التثبيت لنظام التشغيل ذي الأهمية من موقعنا . بالنسبة لنظام Linuxoids ، من الممكن تثبيت حزمة مبكرة . نأمل حقًا أن تصل أيدي متجر Microsoft Store و App Store قريبًا (هل تحتاجها؟ ما رأيك؟).

سيناريو تجريبي

كموضوع اختبار ، اخترنا السيناريو القياسي التالي:

• تسجيل الدخول: المستخدم - المسؤول ، كلمة المرور - كلمة المرور
• إضافة إدخال جديد
• تحقق من إضافة الإدخال الصحيح

سنختبر في https://testmace-quick-start.herokuapp.com/ . هذا خادم json منتظم ، مثالي لاختبار هذه التطبيقات. لقد أضفنا إذنًا رمزيًا إلى جميع مسارات خادم json وقمنا باستخدام طريقة تسجيل الدخول للحصول على هذا الرمز المميز. سوف نمضي قدمًا في تحسين مشروعنا تدريجياً.

إنشاء مشروع ومحاولة إنشاء كيان دون ترخيص

أولاً ، قم بإنشاء مشروع جديد ( ملف -> مشروع جديد ). إذا كنت تقوم بتشغيل التطبيق لأول مرة ، فسيتم فتح مشروع جديد تلقائيًا. أولاً ، دعونا نحاول تقديم طلب لإنشاء سجل جديد (فجأة ، يكون إنشاء سجلات متاحًا دون إذن). حدد إضافة عقدة -> RequestStep من قائمة السياق لعقدة Project. عيّن اسم العقدة لإنشاء النشر . نتيجة لذلك ، سيتم إنشاء عقدة جديدة في الشجرة وسيتم فتح علامة تبويب هذه العقدة. وضعنا معلمات الاستعلام التالية:

• نوع الطلب: POST
• عنوان url: https://testmace-quick-start.herokuapp.com/posts
• نص الطلب: json بالقيمة {"title": "New testmace quick start post"}
  إذا قمت بكل شيء بشكل صحيح ، فستظهر الواجهة بالشكل التالي:

ومع ذلك ، إذا حاولنا تلبية الطلب ، فسيرجع الخادم إلى رمز 401 وبدون إذن ، لا يوجد شيء يضيء على هذا الخادم. حسنا ، بشكل عام ، كما هو متوقع).

إضافة طلب إذن

كما ذكرنا سابقًا ، لدينا نقطة نهاية /login POST يقبل طلب json باعتباره نص الطلب: {"username": "<username>", "password": "<password>"} ، حيث username password (مرة أخرى من المقدمة أعلاه) لديها قيم admin password على التوالي. استجابةً لذلك ، تقوم نقطة النهاية بإرجاع json النموذج {"token": "<token>"} . سوف نستخدمها للترخيص. قم بإنشاء عقدة RequestStep باستخدام اسم تسجيل الدخول ، وستعمل عقدة Project كجد . استخدم السحب والإفلات لتحريك العقدة المحددة في الشجرة أعلى من عقدة إنشاء النشر . دعونا نضع المعلمات التالية للاستعلام المنشأ حديثًا:

• نوع الطلب: POST
• عنوان url: https://testmace-quick-start.herokuapp.com/login
• طلب النص: json بالقيمة {"username": "admin", "password": "password"}

ننفذ الطلب ونحصل على كود مائتي برمز في الرد. شيء مثل هذا:

إعادة بيع الديون: إزالة ازدواجية المجال

بينما لا يتم توصيل الطلبات في برنامج نصي واحد. ولكن هذا ليس العيب الوحيد. إذا نظرت عن كثب ، ستلاحظ أن المجال على الأقل يتكرر في كلا الاستعلامات. انها ليست جيدة. حان الوقت لإعادة تفعيل هذا الجزء من السيناريو في المستقبل وسوف تساعدنا المتغيرات في ذلك.

في التقريب الأول ، تؤدي المتغيرات نفس دور الأدوات ولغات البرمجة الأخرى المتشابهة - مما يؤدي إلى التخلص من الازدواجية وزيادة إمكانية القراءة وما إلى ذلك. يمكنك قراءة المزيد عن المتغيرات في وثائقنا . في هذه الحالة ، نحتاج إلى متغيرات مخصصة.

نحدد متغير domain على مستوى المشروع من العقدة مع القيمة https://testmace-quick-start.herokuapp.com . لهذا فمن الضروري

• افتح علامة تبويب بها هذه العقدة وانقر على أيقونة الحاسبة في أعلى اليمين
• انقر فوق + إضافة متغير
• أدخل اسم وقيمة المتغير
  في حالتنا ، سيبدو مربع الحوار مع المتغير المضافة كما يلي:

OK. الآن ، بسبب الميراث ، يمكننا استخدام هذا المتغير في أحفاد أي مستوى من التعشيش. في حالتنا ، هذه هي العقد تسجيل الدخول وإنشاء بعد . من أجل استخدام متغير في حقل النص ، من الضروري كتابة ${<variable_name>} . على سبيل المثال ، يتم تحويل عنوان url الخاص بتسجيل الدخول إلى ${domain}/login ، على التوالي ، لعقدة إنشاء رابط url ستظهر مثل ${domain}/posts .

وبالتالي ، واسترشادا بمبدأ DRY ، قمنا بتحسين السيناريو بشكل طفيف.

نحن نحفظ الرمز المميز في متغير

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

للبدء ، سنقوم بتنفيذ طلب تسجيل الدخول. في علامة التبويب Parsed للاستجابة ، مرّر الماوس فوق الرمز المميز وفي قائمة السياق (والتي يطلق عليها إما زر الماوس الأيمن أو بالنقر فوق الزر ...) ، حدد Assign to variable . يظهر مربع حوار مع الحقول التالية:

• المسار - أي جزء من الاستجابة يتم اتخاذها (في حالتنا ، هذا هو body.token )
• القيمة الحالية - ما هي القيمة الموجودة على طول مسار المسار (في حالتنا ، هذه هي قيمة الرمز المميز)
• اسم المتغير - اسم المتغير حيث سيتم تخزين القيمة الحالية . في حالتنا ، سيكون token
• العقدة - في أي من الأسلاف سيتم إنشاء متغير اسم المتغير. اختيار المشروع

مربع الحوار المكتمل كالتالي:

الآن ، في كل مرة يتم فيها تنفيذ عقدة تسجيل الدخول ، سيتم تحديث token الحيوي بالقيمة الجديدة من الاستجابة. وسيتم تخزين هذا المتغير في عقدة المشروع ، وبسبب الوراثة ستكون متاحة للأحفاد.

للوصول إلى المتغيرات الديناميكية ، تحتاج إلى استخدام المتغير $dynamicVar . على سبيل المثال ، للوصول إلى الرمز المميز المخزن ، تحتاج إلى استدعاء ${$dynamicVar.token} .

نلقي رمزية إذن في الطلبات

في الخطوات السابقة ، تلقينا رمزًا للترخيص وكل ما يجب القيام به هو إضافة عنوان Authorization ذي القيمة Bearer <tokenValue> إلى جميع الطلبات التي تتطلب تخويلًا ، بما في ذلك إنشاء Bearer <tokenValue> . هناك عدة طرق للقيام بذلك:

1. قم بنسخ الرمز المميز يدويًا وأضف رأس التفويض إلى طلبات الاهتمام. الطريقة تعمل ، لكن تطبيقه محدود فقط من خلال طلبات النموذج "المقدمة والقيت". غير مناسب للبرامج النصية المتعددة
2. استخدام وظيفة التخويل .
3. استخدم الرؤوس الافتراضية

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

شيء آخر هو الرؤوس الافتراضية! باختصار ، الرؤوس الافتراضية هي رؤوس HTTP الموروثة من الأسلاف ، والتي تتم إضافتها إلى الطلب بشكل افتراضي ، إذا لم يتم تعطيلها بشكل صريح. باستخدام هذه الوظيفة ، على سبيل المثال ، يمكنك تطبيق التفويض المخصص أو مجرد التخلص من التكرار في البرامج النصية. سنستخدم هذه الميزة لإرم الرمز المميز في الرؤوس.

في وقت سابق ، قمنا بحفظ الرمز المميز في المتغير الديناميكي $dynamicVar.token على مستوى المشروع في العقدة. يبقى القيام بما يلي:

1. حدد رأس Authorization الافتراضي بقيمة Bearer ${$dynamicVar.token} عند مستوى المشروع في العقدة. للقيام بذلك ، في واجهة Project في العقدة ، تحتاج إلى فتح مربع حوار مع الرؤوس الافتراضية (زر الرؤوس في الزاوية اليمنى العليا) وإضافة العنوان المقابل. سيبدو مربع الحوار مع القيم المملوءة كما يلي:
   
2. تعطيل هذا الرأس من طلب تسجيل الدخول. هذا أمر مفهوم: في وقت تسجيل الدخول ، ما زلنا لا نملك رمزًا مميزًا وسنقوم فقط بتثبيته مع هذا الطلب. لذلك ، في واجهة طلب تسجيل الدخول في علامة تبويب الرؤوس في المنطقة الوراثية ، قم بإلغاء تحديد رأس التفويض.

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

التحقق من صحة إنشاء وظيفة

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

• إرسال طلب للحصول على وظيفة من قبل معرف ،
• تحقق من تطابق الاسم الوارد من الخادم مع الاسم المعطى عند إنشاء المنشور

النظر في الخطوة الأولى. بمجرد تحديد قيمة المعرف أثناء تنفيذ البرنامج النصي ، ستحتاج إلى إنشاء متغير ديناميكي (دعنا نسميها postId ) من عقدة إنشاء النشر على مستوى المشروع في العقدة. نحن نعرف بالفعل كيفية القيام بذلك ، فقط انتقل إلى القسم " حفظ الرمز المميز في متغير" . يبقى فقط لإنشاء طلب لنشر على هذا المعرف. للقيام بذلك ، قم بإنشاء get-post get-post مع المعلمات التالية:

• نوع الطلب: الحصول على
• عنوان URL: $ {domain} / posts / $ {$ dynamicVar.postId}

لتنفيذ الخطوة الثانية ، نحتاج إلى التعرف على عقدة التأكيد . تأكيد العقدة هي عقدة تسمح لك بكتابة الشيكات لطلبات محددة. يمكن أن تحتوي كل عقدة تأكيد على عدة عبارات (اختبارات). يمكنك قراءة المزيد حول جميع أنواع التأكيدات من وثائقنا. سنستخدم Compare التأكيد مع المشغل equal . هناك عدة طرق لإنشاء تأكيدات:

1. منذ فترة طويلة. يدوياً من قائمة السياق لعقدة RequestStep إنشاء عقدة تأكيد. في العقدة التي أنشأتها Assertion ، أضف تأكيد الاهتمام واملأ الحقول.
2. خيارات. إنشاء عقدة تأكيد مع تأكيد من استجابة RequestStep للعقدة باستخدام قائمة السياق

سوف نستخدم الطريقة الثانية. هنا هو كيف سيبحث عن قضيتنا.

بالنسبة لأولئك الذين لا يفهمون ، يحدث ما يلي:

1. قم بتقديم طلب في عقدة get-post
2. في علامة التبويب Parsed للاستجابة ، اتصل بقائمة السياق وحدد Create assertion -> Compare -> Equal

مبروك ، لقد أنشأنا أول اختبار! بسيط ، أليس كذلك؟ الآن يمكنك تشغيل البرنامج النصي بالكامل والاستمتاع بالنتيجة. يبقى أن refactor قليلا ووضع title في متغير منفصل. ولكن سوف نترك الأمر لك كواجب منزلي)

استنتاج

في هذا الدليل ، أنشأنا نصًا كاملاً واستعرضنا في الوقت نفسه بعض ميزات منتجنا. بالطبع ، لم نستخدم جميع الوظائف ، وفي المقالات التالية سنجري مراجعة مفصلة لقدرات TestMace. ترقبوا!

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