كتابة اختبارات القبول واختبارات المكونات لكود Ember في Discourse

[Discourse]

الاختبارات الآلية هي طريقة ممتازة لحماية كودك من التراجعات المستقبلية. كثير من الناس على دراية بكيفية القيام بذلك في قاعدة كود Rails لدينا باستخدام rspec، لكن جانب Javascript قد يكون غامضًا للبعض.

لحسن الحظ، أصبح من السهل جدًا هذه الأيام إضافة اختبارات أساسية إلى كود Ember!

اختبارات المكونات

في الدورة السابقة ضمن هذه السلسلة، أضفنا مكونًا يُسمى fancy-snack لعرض وجبة خفيفة مع خلفية تتلاشى. دعنا نكتب اختبارًا له. أنشئ الملف التالي:

test/javascripts/components/snack-test.js

import componentTest from "helpers/component-test";

moduleForComponent("fancy-snack", { integration: true });

componentTest("اختبار العرض", {
  template: "{{fancy-snack snack=testSnack}}",

  setup() {
    this.set("testSnack", {
      name: "رقائق البطاطس",
      description: "الآن مع دهون متحولة إضافية!",
    });
  },

  test(assert) {
    assert.equal(this.$(".fancy-snack-title h1").text(), "رقائق البطاطس");
    assert.equal(
      this.$(".fancy-snack-description p").text(),
      "الآن مع دهون متحولة إضافية!"
    );
  },
});

لتشغيل الاختبار، افتح متصفحك على خادم التطوير الخاص بك على /qunit?module=component%3Afancy-snack. سيقوم متصفحك بعد ذلك بتشغيل اختبارات المكون وإخراج شيء مثل “تم تمرير 2 من 2 ادعاءات، 0 فشلت.”

لاحظ أنه بينما تكون على صفحة /qunit يمكنك تشغيل اختبارات أخرى. يمكنك ببساطة اختيار اختبار جديد من قائمة Module المنسدلة في أعلى الشاشة.

دعنا نمر خطوة بخطوة عبر الاختبار لفهم كيفية عمله.

تخبر سطر template Ember بكيفية إدراج مكوننا. إنه نفس ترميز HTML الذي ستستخدمه لوضع المكون في قالب Handlebars، لذا يجب أن يكون مألوفًا:

template: '{{fancy-snack snack=testSnack}}',

لاحظ أنه يتم تمرير testSnack كمعامل snack. يتم تعريف ذلك في دالة setup():

setup() {
  this.set('testSnack', {
    name: 'رقائق البطاطس',
    description: 'الآن مع دهون متحولة إضافية!'
  });
},

لقد وضعت بعض البيانات الوهمية. كل ما نحتاج إلى فعله هو تمكين Ember من عرض المكون. أخيرًا، لدينا بعض الادعاءات في دالة test():

test(assert) {
  assert.equal(this.$('.fancy-snack-title h1').text(), 'رقائق البطاطس');
  assert.equal(this.$('.fancy-snack-description p').text(), 'الآن مع دهون متحولة إضافية!');
}

إذا استخدمت this.$() فستحصل على إمكانية الوصول إلى محدد jQuery في قالبك. تستخدم الادعاءات هنا هذا المحدد لاستخراج قيمة عنوان الوجبة الخفيفة ووصفها ومقارنتها بما نتوقعه. إذا تطابقت القيم، فستمر الادعاءات وسيكون اختبارنا يعمل بشكل صحيح.

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

اختبارات القبول

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

إليك كيف يمكننا كتابة اختبار قبول سيزور مسار /admin/snack ويؤكد تم عرض الوجبة الخفيفة:

test/javascripts/acceptance/snack-test.js

import { acceptance } from "helpers/qunit-helpers";
acceptance("Snack");

test("زيارة الصفحة", function (assert) {
  visit("/admin/snack");
  andThen(() => {
    assert.ok(exists(".fancy-snack-title"), "عنوان الوجبة الخفيف موجود");
  });
});

دالة test() في هذه الحالة تكاد تُقرأ كإنجليزية! الأمر الأول يقول زيارة عنوان URL /admin/snack. بعد ذلك، هناك دالة andThen(). هذه الدالة ضرورية للتأكد من انتهاء جميع الأعمال الخلفية قبل استمرار الاختبارات. بما أن كود Javascript و Ember غير متزامن، فنحن بحاجة إلى التأكد من أن Ember قد انتهى من كل ما يحتاج إلى فعله قبل تنفيذ ادعاءاتنا. أخيرًا، يختبر لمعرفة ما إذا كان عنصر .fancy-snack-title موجودًا.

ومع ذلك، إذا قمت بتشغيل هذا الاختبار بزيارة /qunit?module=Acceptance%3A%20Snack ستجد أن الاختبار سيفشل بسبب خطأ AJAX.

إذا كنت تتذكر، فإن كودنا يتضمن جانب Rails وجانب Javascript قام بطلب AJAX للحصول على بياناته. قام اختبار القبول بتشغيل جانب Javascript، لكنه لم يعرف كيفية الحصول على بياناته من Rails.

لإصلاح ذلك، نحتاج إلى إضافة استجابة وهمية باستخدام مكتبة pretender الممتازة. افتح ملف test/javascripts/helpers/create-pretender.js وابحث عن السطر الذي يقول:

this.get("/admin/plugins", () => response({ plugins: [] }));

تحت هذا السطر مباشرة، أضف سطرًا لإرجاع كائن وجبة خفيفة وهمي ليعمل معه اختبار القبول:

this.get("/admin/snack.json", () => {
  return response({ name: "اسم الوجبة الخفيفة", description: "وصف الوجبة الخفيفة" });
});

يمكنك قراءة الكود أعلاه كالتالي: “لأي طلب إلى /admin/snack.json، استجب بالـ response التالي.”

إذا قمت بتحديث عنوان URL /qunit?module=Acceptance%3A%20Snack، فسيستعيد اختبار القبول بياناته عبر pretender ويجب أن تمر الاختبارات.

أين تذهب من هنا

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

---

يتم التحكم في إصدار هذا المستند - اقترح تغييرات على GitHub.

[Mittineague]

My prior experience in writing qunit tests was based on the other howto

Developing Discourse Plugins - Part 6 - Add acceptance tests

Previous tutorial: Developing Discourse Plugins - Part 5 - Add an admin interface Did you know that Discourse has two large test suites for its code base? On the server side, our Ruby code has a test suite that uses rspec. For the browser application, we have a qunit suite that has ember-testing included. Assuming you have a development environment set up, if you visit the http://localhost:4200/tests URL you will start running the JavaScript test suite in your browser. One fun aspect is that …

i.e. “acceptance” was simply

acceptance("Purple Tentacle", { loggedIn: true });

I have seen in other plugins where the test code contained “fake” JSON to test against. I wasn’t sure if that would be as good as testing against “real” data, so I wanted to avoid doing it that way.

The six tests passed, but I got a couple of rather angry looking “unhandled request” errors.

After finding an example of some “setup” code, I tried it and it solved the errors.

test/javascripts/acceptance/discourse-newpage-test.js.es6

It works, but I’m not really sure why, nor why it’s needed for some but not for the majority of plugins I’ve seen that have qunit tests.

[eviltrout (Robin Ward)]

For a long time we weren’t great with testing plugins, so not many people followed our example and added tests.

You are right to add a response using pretender to handle AJAX calls.

[davidag (David)]

ملاحظة فقط بأن المسار /qunit لم يعد مستخدماً. إنه /tests الآن. استغرق الأمر مني بعض الوقت لفهم ذلك