إختبر مكونات واجهة المستخدم

لا يكتمل درس ستوريبوك بدون القيام باختبارات. الاختبار أساسي لإنشاء واجهات ذات جودة عالية. في الأنظمة المركبة, التعديلات المصغرة قد تنتج نتائج كبيرة. تعرفنا إلى الآن على ثلاث أنواع من الاختبارات:

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

“و لكن هل مظهرها صحيح؟”

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

الاختبار المظهري لستوريبوك

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

ستوريبوك أداة رائعة لأداء اختبار تراجع مظهري لأن كل ستوري عبارة عن مواصفات اختبار في الأساس. كلما نكتب أو نغير في ستوري, نحصل على مواصفات مجانا!

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

إلتقط التغيرات في واجهة المستخدم

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

لنرى طريقة عمله بتعديل خلفية مكون Task

ابدأ بإنشاء فرع git جديد من أجل هذا التغيير:

git checkout -b change-task-background

قم بتغيير src/components/Task.js إلى الآتي:

<div className="title">
  <input
    type="text"
    value={title}
    readOnly={true}
    placeholder="Input title"
+   style={{ backgroundColor: 'red' }}
  />
</div>

هذا سيٌنتج لون خلفية جديد للعنصر

أضف الملف:

git add .

نفذه:

git commit -m "change task background to red"

و ادفع التغييرات إلى المستودع البعيد:

git push -u origin change-task-background

أخيرا, إفتح مستودع Github وقم بطلب سحب pull request لفرع change-task-background

أضف نص وصف في طلب السحب وإضغط Create pull request. إضغط على إختيار "🟡 UI Tests" في أسفل الصفحة.

هذا سيٌظهر لك التغيرات في الواجهة التي إلتقطت من تنفيذتك

يوجد الكثير من التغييرات! السلسلة الهرمية حيث Task عنصر تابع ل TaskList وInbox يعني تغيير بسيط يكبر ليصبح تراجع عملاق. هذا الظرف بالتحديد هو السبب الذي يجعل المطورين في حاجة إلى اختبار تراجع مظهري إضافة إلى سبل اختبار أخرى.

راجع التغييرات

يضمن اختبار التراجع الظاهري أن المكونات لا تتغير خطأً. ولكن لا يزال الأمر متروكا لنا لتحديد ما إذا كانت هذه التغييرات مقصودة أم لا.

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

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

إدمج التغييرات

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

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