اختبار البيئات

يتناول هذا المستند العوامل التي يمكن أن تؤثر على بيئتك والتوصيات المتعلقة ببعض السيناريوهات.

منفذو الاختبار

• يتيح لك منفذو الاختبار مثل Jest, mocha, ava كتابة مجموعات اختبار على هيئه JavaScript وتشغيلها بصفتها جزءا من عملية التطوير الخاصة بك. بالإضافة إلى ذلك يتم تشغيل مجموعات الاختبار بصفتها جزءا من التكامل المستمر (CI).
• Jest متوافق على نطاق واسع مع مشاريع React، ودعم مميزات جديدة مثل الوحدات النمطيةو العداد ودعم jsdom. إذا كنت تستخدم Create React App إذن Jest موجود بالفعل مع تسطيب افتراضي مفيد.
• المكتبات مثل mocha تعمل بشكل جيد في بيئات المتصفح الحقيقي، ويمكن أن تساعد في الاختبارات التي تحتاجها بشكل صريح.
• تُستخدم اختبارات End-to-End لاختبار تدفقات أطول عبر عدة صفحات، وتتطلب إعدادات مختلفة.

محاكاة واجهة التصيير

تعمل الاختبارات غالبًا في بيئة دون الوصول إلى واجهة التصيير الحقيقية مثل المتصفح. بالنسبة لهذه البيئات، نوصي بمحاكاة متصفح باستخدام jsdom ، وهو تطبيق متصفح خفيف الوزن يعمل داخل Node.js.

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

تمامًا كما في المتصفح الحقيقي، تتيح لنا jsdom تصميم تفاعلات المستخدم؛ يمكن للاختبارات إرسال الأحداث في عقدات DOM، ثم مراقبة الآثار الجانبية لهذه الإجراءات والتأكيد عليها (مثال).

يمكن كتابة جزء كبير من اختبارات واجهة المستخدم باستخدام الإعداد أعلاه: استخدام Jest كمنفذ للاختبار، يتم تصييره إلى jsdom ، مع تفاعلات المستخدم المحددة كسلسلة من أحداث المتصفح، مدعومًا بـالمساعد act () (مثال). على سبيل المثال، تتم كتابة الكثير من اختبارات React الخاصة مع هذه التركيبة.

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

في بيئة لا يمكنك فيها محاكاة DOM (على سبيل المثال، اختبار مكونات React Native على Node.js) ، يمكنك استخدام مساعدي محاكاة الأحداث لمحاكاة التفاعلات مع العناصر. بالتناوب، يمكنك استخدام fireEvent المساعد من @ testing-library/react-native.

إطارات عمل مثل Cypress و puppeteer و webdriver مفيدة لتشغيل اختبارات end-to-end.

محاكاة الدوال

عند كتابة الاختبارات، نود أن نحاكى الشفرة الخاص بنا التي لا تحتوى على مُمَاثل لها فى بيئة الاختبار الخاصة بنا (على سبيل المثال التحقق من حالة navigator.onLin داخل Node.js). يمكن للاختبارات أيضًا التجسس على بعض الدوال، ومراقبة كيفية تفاعل أجزاء أخرى من الاختبار معها. من المفيد عندئذ أن تكون قادرًا على محاكاة هذه الدوال باصدارات سهلة الاستخدام بشكل الانتقائي.

هذا مفيد بشكل خاص لجلب البيانات. من المفضل عادة استخدام البيانات “المزيفة” للاختبارات لتجنب البطء والضعف بسبب الجلب من نقاط الوصول النهائية لواجهة برمجة التطبيقات الحقيقية. (مثال) . هذا يساعد على جعل الاختبارات يمكن التنبؤ بها. مكتبات مثل Jest و sinon، من بين مكونات أخرى، تدعم محاكاه الدوال. بالنسبة لاختبارات الـ end-to-end ، يمكن أن تكون محاكاة الشبكة أكثر صعوبة، ولكن قد ترغب أيضًا في اختبار نقاط الوصول الحقيقية لواجهة برمجة التطبيقات فيها.

محاكاه الوحدات

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

على Node.js ، يقوم منفذو الاختبارات مثل Jest بدعم محاكاة الوحدات. يمكنك أيضًا استخدام مكتبات مثل mock-require.

محاكاة المؤقتات

قد تستخدم المكونات وظائف تستند إلى الوقت مثل setTimeout أوsetInterval أو Date.now. في بيئات الاختبار، قد يكون من المفيد الاستغناء عن هذه الوظائف مع البدائل التي تتيح لك “التقدم” يدويًا. هذا شيء عظيم للتأكد من أن اختباراتك تعمل بسرعة! الاختبارات التي تعتمد على العداد ستظل قائمة بالترتيب، ولكن أسرع (مثال). معظم أطر العمل، بما في ذلك Jest ، sinon و lolex ، تتيح لك محاكاة العداد في اختباراتك.

في بعض الأحيان، قد لا ترغب في محاكاة العداد. على سبيل المثال، ربما تقوم باختبار رسم متحرك، أو تتفاعل مع نقطة نهاية حساسة للتوقيت (مثل واجهة برمجة التطبيقات من نوع API rate limiter). تتيح لك المكتبات التي بها محاكاه العداد تمكينها وتعطيلها على أساس كل اختبار/مجموعة، بحيث يمكنك اختيار كيفية تشغيل هذه الاختبارات بشكل صريح.

اختبارات end-to-end

تعد اختبارات end-to-end مفيدة لاختبار سير عمل أطول، خاصةً عندما تكون مهمة لنشاطك التجاري (مثل المدفوعات أو الاشتراكات). بالنسبة لهذه الاختبارات، قد ترغب في اختبار كلٍّ من كيفية عرض المتصفح الحقيقي للتطبيق بأكمله، وجلب البيانات من نقاط الوصول الحقيقية لواجهة برمجة التطبيقات، واستخدام الجلسات (session) وملفات تعريف الارتباط (cookies)، والتنقل بين الروابط المختلفة. قد ترغب أيضًا في تقديم تأكيدات ليس فقط في حالة DOM، ولكن أيضًا على بيانات النسخ الاحتياطي (على سبيل المثال للتحقق من استمرار التحديثات في قاعدة البيانات).

في هذا السيناريو، يمكنك استخدام إطار عمل مثل Cypress أو مكتبة مثل puppeteer حتى تتمكن من التنقل و تصفح بين نقاط الوصول والطرق (routes) المتعددة والتأكيد على الآثار الجانبية ليس فقط في المتصفح، ولكن يحتمل أن يكون على الواجهة الخلفية (back-end) أيضًا.