أهلاً بكم. نحن نخرج ببطء من الظل ونواصل سلسلة المقالات حول منتجنا. بعد مقالة المراجعة، تلقينا الكثير من التعليقات (الإيجابية في الغالب) والاقتراحات وتقارير الأخطاء. اليوم سوف نعرض في العمل وسوف تكون قادرًا على تقدير بعض ميزات تطبيقنا. للحصول على انغماس أكثر اكتمالا، أنصحك بالرجوع إلى وثائقنا على . إذا هيا بنا!
تركيب
لنبدأ بالابتذال. التطبيق متاح وتم اختباره بالفعل على ثلاث منصات - Linux، Windows، MacOS. يمكنك تنزيل برنامج التثبيت لنظام التشغيل الذي تهتم به من خلاله . لمستخدمي Linux من الممكن التثبيت . نأمل حقًا أن يتمكن متجر Microsoft Store ومتجر التطبيقات من الوصول إليه قريبًا (هل هذا ضروري؟ ما رأيك؟).
السيناريو التجريبي
لقد اخترنا السيناريو القياسي التالي كموضوع اختبار لدينا:
- تسجيل الدخول: المستخدم - المشرف، كلمة المرور - كلمة المرور
- إضافة إدخال جديد
- دعونا نتحقق من إضافة السجل بشكل صحيح
سوف نقوم باختبار على . انه عادي مثالية لاختبار مثل هذه التطبيقات. لقد أضفنا للتو ترخيصًا بواسطة الرمز المميز إلى جميع مسارات خادم json وأنشأنا طريقة تسجيل دخول لتلقي هذا الرمز المميز. سوف نتحرك تدريجيًا ونحسن مشروعنا تدريجيًا.
إنشاء مشروع ومحاولة إنشاء كيان دون ترخيص
أولاً، لنقم بإنشاء مشروع جديد (قم بتقديم->مشروع جديد). إذا كنت تقوم بتشغيل التطبيق لأول مرة، فسيتم فتح مشروع جديد تلقائيًا. أولاً، دعونا نحاول تقديم طلب لإنشاء سجل جديد (في حالة توفر إنشاء السجلات بدون تصريح). حدد عناصر من قائمة سياق عقدة المشروع أضف عقدة -> خطوة الطلب. اضبط اسم العقدة على إنشاء مشاركة. ونتيجة لذلك، سيتم إنشاء عقدة جديدة في الشجرة وسيتم فتح علامة تبويب لهذه العقدة. لنقم بتعيين معلمات الطلب التالية:
- نوع الطلب: بريد
- رابط:
- نص الطلب: json بقيمة
{"title": "New testmace quick start post"}
إذا قمت بكل شيء بشكل صحيح، فستبدو الواجهة كما يلي:
ومع ذلك، إذا حاولنا تلبية الطلب، فسيقوم الخادم بإرجاع رمز 401 وبدون ترخيص لن نحصل على أي شيء على هذا الخادم. حسنا، بشكل عام، كما هو متوقع).
إضافة طلب ترخيص
كما قلنا سابقًا، لدينا نقطة نهاية POST /login، والذي يأخذ json كنص طلب للنموذج: {"username": "<username>", "password": "<password>"}حيث username и password (مرة أخرى، من الفقرة التمهيدية أعلاه) لها معاني admin и password على التوالى. ردًا على ذلك، تُرجع نقطة النهاية هذه json like {"token": "<token>"}. سوف نستخدمها للحصول على إذن. دعونا نخلق خطوة الطلب العقدة بالاسم تسجيل الدخول، سيكون بمثابة الجد حملات التبرع العقدة باستخدام السحب والإفلات، قم بتحريك عقدة معينة في الشجرة أعلى من العقدة إنشاء مشاركة. لنقم بتعيين المعلمات التالية للطلب الذي تم إنشاؤه حديثًا:
- نوع الطلب: بريد
- رابط:
- نص الطلب: json بقيمة
{"username": "admin", "password": "password"}
لننفذ الطلب ونتلقى الرمز المائتين مع الرمز المميز في الرد. شيء من هذا القبيل:
إعادة البناء: إزالة ازدواجية المجال
حتى الآن لم يتم ربط الطلبات في برنامج نصي واحد. ولكن هذا ليس العيب الوحيد. إذا نظرت عن كثب، ستلاحظ أن النطاق على الأقل مكرر في كلا الطلبين. ليس جيدا. لقد حان الوقت لإعادة بناء هذا الجزء من البرنامج النصي المستقبلي، وستساعدنا المتغيرات في ذلك.
كتقريب أولي، تؤدي المتغيرات نفس الدور كما هو الحال في الأدوات ولغات البرمجة الأخرى المماثلة - مما يؤدي إلى القضاء على الازدواجية، وزيادة سهولة القراءة، وما إلى ذلك. يمكنك قراءة المزيد عن المتغيرات في . في هذه الحالة، سنحتاج إلى متغيرات المستخدم.
دعونا نحدد متغيرًا على مستوى عقدة المشروع domain مع معنى https://testmace-quick-start.herokuapp.com. لهذا فمن الضروري
- افتح علامة التبويب بهذه العقدة وانقر على أيقونة الآلة الحاسبة في أعلى اليمين
- انقر فوق + إضافة متغير
- أدخل اسم المتغير وقيمته
في حالتنا، سيبدو مربع الحوار مع المتغير المضاف كما يلي:
نعم. الآن، بسبب الوراثة، يمكننا استخدام هذا المتغير في أحفاد أي مستوى تداخل. في حالتنا هذه هي العقد تسجيل الدخول и إنشاء مشاركة. من أجل استخدام متغير في حقل النص، تحتاج إلى الكتابة ${<variable_name>}. على سبيل المثال، يتم تحويل عنوان URL لتسجيل الدخول إلى ${domain}/loginعلى التوالي ل إنشاء مشاركة سيبدو عنوان URL للعقدة ${domain}/posts.
وبالتالي، واسترشادًا بمبدأ الجفاف، قمنا بتحسين السيناريو قليلاً.
احفظ الرمز المميز في متغير
وبما أننا نتحدث عن المتغيرات، دعونا نتوسع في هذا الموضوع قليلاً. في الوقت الحالي، في حالة تسجيل الدخول بنجاح، نتلقى من الخادم رمزًا مميزًا للتفويض، والذي سنحتاج إليه في الطلبات اللاحقة. دعونا نحفظ هذا الرمز المميز في متغير. لأن سيتم تحديد قيمة المتغير أثناء تنفيذ البرنامج النصي، ونستخدم آلية خاصة لذلك - .
أولاً، لننفذ طلب تسجيل الدخول. في علامة التبويب معرب الإجابة، حرك المؤشر فوق الرمز المميز وفي قائمة السياق (التي يتم استدعاؤها إما بزر الفأرة الأيمن أو بالنقر فوق الزر ...) حدد العنصر إسناد إلى متغير. سيظهر مربع حوار يحتوي على الحقول التالية:
- مسار - أي جزء من الإجابة مأخوذ (في حالتنا هو
body.token) - القيمة الحالية - ما هي القيمة الموجودة على طول المسار (في حالتنا هذه هي قيمة الرمز المميز)
- اسم المتغير - اسم المتغير حيث القيمة الحالية سيتم الحفاظ عليها. في حالتنا سيكون
token - العقدة - في أي من الأسلاف سيتم إنشاء المتغير اسم المتغير. دعونا نختار المشروع
يبدو مربع الحوار المكتمل كما يلي:
الآن في كل مرة يتم تنفيذ العقدة تسجيل الدخول متغير ديناميكي token سيتم تحديثه بالقيمة الجديدة من الاستجابة. وسيتم تخزين هذا المتغير في حملات التبرع العقدة، وبفضل الميراث، ستكون متاحة للأحفاد.
للوصول إلى المتغيرات الديناميكية، يجب عليك استخدام $dynamicVar. على سبيل المثال، للوصول إلى الرمز المميز المخزن، تحتاج إلى الاتصال ${$dynamicVar.token}.
نقوم بتمرير رمز التفويض إلى الطلبات
لقد حصلنا في الخطوات السابقة على رمز التفويض وكل ما يتعين علينا فعله هو إضافة رأس Authorization مع معنى Bearer <tokenValue> في جميع الطلبات التي تتطلب إذنًا، بما في ذلك إنشاء مشاركة. هناك عدة طرق للقيام بذلك:
- انسخ الرمز المميز يدويًا وأضف رأس الترخيص إلى طلبات الاهتمام. تعمل الطريقة، لكن استخدامها يقتصر فقط على الطلبات من النوع "المصنوعة والمرمىة". غير مناسب للتنفيذ المتكرر للنصوص البرمجية
- استخدم الوظيفة .
- استخدم
يبدو استخدام الطريقة الثانية واضحًا، ولكن في سياق هذه المقالة، فإن هذا النهج... غير مثير للاهتمام. حسنًا، حقًا: آلية التفويض زائد ناقص مألوفة لك من الأدوات الأخرى (حتى لو كان لدينا أشياء مثل ) ومن غير المرجح أن يثير أسئلة.
شيء آخر هو الرؤوس الافتراضية! باختصار، الرؤوس الافتراضية هي رؤوس HTTP الموروثة والتي تتم إضافتها إلى الطلب افتراضيًا ما لم يتم تعطيلها بشكل صريح. باستخدام هذه الوظيفة، يمكنك، على سبيل المثال، تنفيذ ترخيص مخصص أو ببساطة التخلص من الازدواجية في البرامج النصية. دعونا نستخدم هذه الميزة لتمرير رمز مميز في الرؤوس.
في السابق، قمنا بحفظ الرمز المميز في متغير ديناميكي $dynamicVar.token على مستوى عقدة المشروع. كل ما تبقى هو القيام بما يلي:
- تحديد العنوان الافتراضي
Authorizationمع معنىBearer ${$dynamicVar.token}على مستوى عقدة المشروع. للقيام بذلك، في واجهة المشروع الخاصة بالعقدة، تحتاج إلى فتح مربع حوار بالعناوين الافتراضية (زر رؤوس في الزاوية اليمنى العليا) وأضف عنوانًا مطابقًا. سيبدو مربع الحوار بالقيم المملوءة كما يلي:
- قم بتعطيل هذا الرأس من طلب تسجيل الدخول. وهذا أمر مفهوم: في وقت تسجيل الدخول، لم يكن لدينا رمز مميز وسنقوم بتثبيته مع هذا الطلب. لذلك، في واجهة تسجيل الدخول للطلب في علامة التبويب رؤوس في المنطقة موروث قم بإلغاء تحديد رأس التفويض.
هذا كل شئ. سيتم الآن إضافة رأس التفويض إلى جميع الطلبات التابعة لعقدة المشروع، باستثناء عقدة تسجيل الدخول. اتضح أنه في هذه المرحلة لدينا بالفعل نص جاهز وكل ما علينا فعله هو تشغيله. يمكنك تشغيل البرنامج النصي عن طريق التحديد يجري في قائمة سياق عقدة المشروع.
التحقق من صحة إنشاء المنشور
في هذه المرحلة، يمكن للبرنامج النصي الخاص بنا تسجيل الدخول وإنشاء منشور باستخدام رمز التفويض المميز. ومع ذلك، نحتاج إلى التأكد من أن المنشور الذي تم إنشاؤه حديثًا يحمل الاسم الصحيح. وهذا يعني، في جوهره، كل ما تبقى هو القيام بما يلي:
- إرسال طلب لتلقي مشاركة عن طريق الهوية،
- تأكد من أن الاسم المستلم من الخادم يطابق الاسم المرسل عند إنشاء المنشور
دعونا ننظر إلى الخطوة الأولى. نظرًا لأنه يتم تحديد قيمة المعرف أثناء تنفيذ البرنامج النصي، فأنت بحاجة إلى إنشاء متغير ديناميكي (دعنا نسميه postId) من العقدة إنشاء مشاركة على مستوى عقدة المشروع. نحن نعرف بالفعل كيفية القيام بذلك، ما عليك سوى الرجوع إلى القسم احفظ الرمز المميز في متغير. كل ما تبقى هو إنشاء طلب لتلقي منشور باستخدام هذا المعرف. للقيام بذلك، دعونا إنشاء RequestStep الحصول على آخر مع المعلمات التالية:
- نوع الطلب: الحصول على
- عنوان URL: ${domain}/posts/${$dynamicVar.postId}
لتنفيذ الخطوة الثانية، نحن بحاجة للتعرف عليها عقدة. عقدة التأكيد هي عقدة تسمح لك بكتابة الشيكات لطلبات محددة. يمكن أن تحتوي كل عقدة تأكيد على عدة تأكيدات (فحوصات). يمكنك قراءة المزيد عن جميع أنواع التأكيدات من موقعنا . سوف نستخدم Compare التأكيد مع المشغل equal. هناك عدة طرق لإنشاء التأكيدات:
- طويل. قم بإنشاء عقدة تأكيد يدويًا من قائمة السياق الخاصة بعقدة RequestStep. في عقدة التأكيد التي تم إنشاؤها، أضف تأكيد الاهتمام واملأ الحقول.
- سريع. قم بإنشاء عقدة تأكيد مع تأكيد من استجابة عقدة RequestStep باستخدام قائمة السياق
دعونا نستخدم الطريقة الثانية. وهذا ما سيبدو عليه حالتنا.
لمن لم يفهم هذا ما يحدث:
- تقديم طلب في العقدة الحصول على آخر
- في علامة التبويب معرب الإجابة، استدعاء قائمة السياق وحدد إنشاء التأكيد -> المقارنات -> ايكوال
تهانينا، لقد أنشأنا اختبارنا الأول! بسيطة، أليس كذلك؟ يمكنك الآن تشغيل البرنامج النصي بالكامل والاستمتاع بالنتيجة. كل ما تبقى هو إعادة هيكلته قليلاً وإخراجه title في متغير منفصل. لكننا سنترك هذا لك كواجب منزلي)
اختتام
في هذا الدليل، قمنا بإنشاء سيناريو كامل وفي نفس الوقت قمنا بمراجعة بعض ميزات منتجنا. بالطبع، لم نستخدم جميع الوظائف وسنقدم في المقالات التالية نظرة عامة مفصلة عن إمكانيات TestMace. ابقوا متابعين!
ملاحظة: بالنسبة لأولئك الذين هم كسالى جدًا بحيث لا يمكنهم إعادة إنتاج جميع الخطوات، يرجى تسجيلها مع المشروع من المقال. يمكنك فتحه مع قم بتقديم -> مشروع مفتوح وحدد مجلد المشروع.
المصدر: www.habr.com