Jest مقابل Vitest: أي إطار اختبار يجب أن تختار؟

يُعد الاختبار أحد الأسس الرئيسية لبناء تطبيقات JavaScript وTypeScript موثوقة. ومع ازدياد تعقيد تطبيقات الويب الحديثة، تحتاج فرق التطوير إلى إطار اختبار يتوافق مع نظام البناء وبنية التطبيق وسير عمل التطوير وخط أنابيب CI.

لسنوات طويلة، كان Jest أحد أكثر الخيارات انتشارًا في منظومة JavaScript. فهو يوفر تجربة اختبار متكاملة تشمل التحقق من النتائج، والمحاكاة، واختبارات Snapshot، وتغطية الكود، وعزل الاختبارات. أما Vitest فيتبع نهجًا مختلفًا، إذ تم تصميمه مع منظومة Vite في الأساس، مع توفير واجهات برمجية متوافقة مع Jest وإمكانية إعادة استخدام إعدادات Vite وآلية التحويل والإضافات.

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

ما هو Jest؟

Jest هو إطار لاختبار تطبيقات JavaScript، وقد صُمم لتوفير تجربة اختبار متكاملة وبسيطة. ويمكن استخدامه مع مشاريع JavaScript وTypeScript وReact وVue وAngular وNode.js وغيرها.

يوفر Jest العديد من الوظائف الأساسية في بيئة واحدة، بما في ذلك التحقق من النتائج، والمحاكاة، واختبارات Snapshot، وعزل الاختبارات، وتغطية الكود.

على سبيل المثال، يمكن لتطبيق أعمال استخدام Jest لاختبار وظيفة حساب إجمالي الطلب قبل ربطها ببقية مكونات تطبيق React أو Node.js.

test('calculates the order total', () => {
  const total = calculateTotal(100, 20);
  expect(total).toBe(120);
});

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

ما هو Vitest؟

Vitest هو إطار اختبار حديث تم تصميمه مع وضع Vite في الاعتبار. وتتمثل إحدى أهم مزاياه المعمارية في قدرته على إعادة استخدام إعدادات Vite والإضافات وآلية تحويل الوحدات وحل المسارات.

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

كما يوفر Vitest واجهات متوافقة مع Jest، بما في ذلك مفاهيم مثل expect وSnapshots وMocking ومجموعات الاختبار. ومع ذلك، لا تعني هذه التوافقية أن الإطارين متطابقان تمامًا.

Jest مقابل Vitest في لمحة

المجال	Jest	Vitest
النهج الأساسي	إطار اختبار مستقل لـJavaScript	إطار اختبار أصلي لمنظومة Vite
الإعدادات	إعدادات خاصة بـJest	يمكنه إعادة استخدام إعدادات Vite
التحقق من النتائج	واجهات Jest المدمجة	واجهات متوافقة مع Jest مع دعم Chai
المحاكاة	Mocking مدمج في Jest	Mocking متوافق مع Jest عبر vi
Snapshots	مدعومة	متوافقة مع Jest
تغطية الكود	مدعومة ضمن بيئة Jest	دعم V8 وIstanbul
TypeScript وJSX	مدعومان مع إعداد المشروع	دعم مباشر ضمن بيئة Vite
وضع المراقبة	دعم متقدم للمراقبة وتشغيل الاختبارات ذات الصلة	إعادة تشغيل الاختبارات المرتبطة بالتغييرات باستخدام الرسم البياني للوحدات
الاستخدام المثالي	المشاريع القائمة والتكاملات الخاصة بـJest	تطبيقات الويب الحديثة المعتمدة على Vite

الاختلاف المعماري الأهم

الفرق الأساسي بين Jest وVitest لا يكمن في طريقة كتابة الاختبارات فقط، لأن كلاهما يوفر أساليب اختبار مألوفة.

الفرق الأهم يتعلق بكيفية ارتباط بيئة الاختبار ببيئة بناء التطبيق.

لنفترض أن لديك تطبيق Vite يحتوي على TypeScript وJSX ومسارات مخصصة وإضافات وتهيئات خاصة بالبيئة.

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

أما Jest فيعمل كبيئة اختبار مستقلة. ويمكن أن يكون هذا الاستقلال ميزة عندما تريد المؤسسة فصل نظام الاختبار عن أداة البناء، لكنه قد يؤدي إلى إعدادات إضافية في المشاريع التي تعتمد بشكل كبير على خصائص Vite.

تجربة التطوير وسير عمل الاختبارات

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

يجب أن تساعد بيئة الاختبار الجيدة المطور على معرفة الاختبارات المرتبطة بالتغيير بسرعة بدلًا من التعامل مع مجموعة الاختبارات كاملة في كل مرة.

يستفيد Vitest من الرسم البياني للوحدات في Vite لإعادة تشغيل الاختبارات المرتبطة بالتغييرات أثناء وضع المراقبة، مما يمنح المطور تجربة قريبة من فكرة HMR المستخدمة في تطوير Vite.

لكن Jest يوفر أيضًا آليات متقدمة للمراقبة وتنظيم الاختبارات، بما في ذلك إعطاء أولوية للاختبارات التي فشلت سابقًا ومراعاة مدة تنفيذ الاختبارات.

لذلك، كلا الإطارين يوفران تجربة تطوير قوية، لكن Vitest يتميز بتكامله الطبيعي مع نموذج تطوير Vite.

هل Vitest أسرع من Jest؟

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

تعتمد سرعة الاختبارات على عوامل عديدة، منها:

• عدد الاختبارات وحجمها
• تحويل الوحدات
• بنية التطبيق
• استراتيجية المحاكاة
• بيئة DOM
• اتصالات قاعدة البيانات والشبكة
• إعدادات التنفيذ المتوازي
• تغطية الكود
• موارد خادم CI

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

لكن عند مقارنة الأداء في مشروع حقيقي، الأفضل هو اختبار مجموعة الاختبارات الفعلية للمشروع بدل الاعتماد على أرقام عامة.

المحاكاة Mocking في Jest وVitest

تتشابه طريقة كتابة المحاكاة في الإطارين، لكن الواجهات ليست متطابقة.

يستخدم Jest الكائن jest:

const sendEmail = jest.fn();

sendEmail('customer@example.com');

expect(sendEmail).toHaveBeenCalledWith(
  'customer@example.com'
);

بينما يستخدم Vitest الكائن vi:

import { expect, vi, test } from 'vitest';

const sendEmail = vi.fn();

sendEmail('customer@example.com');

expect(sendEmail).toHaveBeenCalledWith(
  'customer@example.com'
);

وهذا يجعل العديد من عمليات الانتقال بسيطة، لكن لا ينبغي اعتبار الإطارين متطابقين في السلوك. توجد اختلافات في الإعدادات وواجهات الاستخدام العامة والمحاكاة والمؤقتات وغيرها.

Snapshots وتغطية الكود

يدعم كلا الإطارين اختبارات Snapshot، مما يسمح بمقارنة مخرجات المكونات أو البيانات المنظمة مع Snapshot متوقعة.

كما يدعم كلاهما تغطية الكود. يوفر Jest هذا ضمن بيئة الاختبار الخاصة به، بينما يدعم Vitest مزودي تغطية مثل V8 وIstanbul.

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

TypeScript وJSX والمشاريع الحديثة

تعتمد تطبيقات الويب الحديثة غالبًا على TypeScript وJSX أو TSX والإضافات والمسارات المخصصة ومتغيرات البيئة وأدوات بناء مختلفة.

يصبح Vitest خيارًا جذابًا بشكل خاص عندما يستخدم المشروع Vite بالفعل، لأنه يستطيع المشاركة في منظومة الأدوات نفسها.

على سبيل المثال، يمكن لفريق يعمل على لوحة تحكم باستخدام React وTypeScript الاستفادة من إعدادات Vite والإضافات والمسارات نفسها أثناء الاختبار.

وفي المقابل، يظل Jest خيارًا قويًا عندما يمتلك التطبيق إعدادًا ناضجًا قائمًا على Jest أو يعتمد على أدوات وتكاملات خاصة به.

الانتقال من Jest إلى Vitest

إحدى نقاط قوة Vitest بالنسبة لمستخدمي Jest هي توافقه مع العديد من واجهات Jest.

لكن الانتقال في مشروع إنتاجي لا ينبغي أن يكون مجرد استبدال كلمات في الملفات.

يجب على الفريق مراجعة:

• إعدادات Jest
• محولات الملفات
• الإضافات والتقارير
• محاكاة الوحدات
• واجهات الاختبار العامة
• المؤقتات الوهمية
• Snapshot serializers
• إعدادات البيئة
• إعدادات التغطية
• أوامر CI

يوفر Vitest دليلًا للانتقال من Jest، ولكنه يوضح أيضًا وجود اختلافات في بعض السلوكيات والإعدادات. لذلك يجب اختبار المشروع فعليًا بعد الانتقال.

متى يكون Jest هو الخيار الأفضل؟

• إذا كان التطبيق يستخدم Jest بالفعل بنجاح.
• إذا كان المشروع يعتمد على تكاملات خاصة بـJest.
• إذا كان الفريق يستخدم أدوات أو تقارير أو محولات مخصصة لـJest.
• إذا كانت بنية الاختبارات الحالية مستقرة ولا توجد مشكلة واضحة تحتاج إلى حل.
• إذا كان المشروع لا يعتمد على Vite ويريد الفريق بيئة اختبار مستقلة.
• إذا كانت خبرة الفريق الأساسية في Jest.

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

متى يكون Vitest هو الخيار الأفضل؟

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

بالنسبة لمشروع جديد يعتمد على Vite، يمكن أن يكون Vitest نقطة بداية طبيعية لأنه يقلل من ازدواجية أدوات التطوير والاختبار.

هل يمكن استخدام Jest وVitest معًا؟

يمكن تقنيًا استخدام إطارين للاختبار، لكن يجب أن يكون ذلك قرارًا مقصودًا.

قد يكون استخدامهما معًا منطقيًا أثناء الانتقال التدريجي من Jest أو عندما تمتلك أجزاء مختلفة من مؤسسة كبيرة متطلبات مختلفة فعلًا.

لكن بالنسبة لتطبيق واحد، فإن الحفاظ على بيئتي اختبار قد يزيد من تعقيد الإعدادات وتكاليف الصيانة وسير عمل CI.

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

كيف يتعامل Code-Ox مع اختيار أدوات الاختبار؟

في Code-Ox، لا يتم التعامل مع الاختبار كمرحلة منفصلة عن هندسة التطبيق. يجب أن تتناسب استراتيجية الاختبار مع بنية النظام ومخاطر الأعمال وسير إصدار البرمجيات والتقنيات المستخدمة.

ففي تطبيق React أو Next.js موجه للعملاء، قد تتضمن الاستراتيجية اختبارات الوحدة لمنطق الأعمال، واختبارات المكونات للتفاعلات المهمة، واختبارات التكامل لواجهات API، وفحوصات آلية ضمن CI.

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

لذلك، يجب اختيار Jest أو Vitest بناءً على احتياجات المشروع الفعلية وليس فقط بناءً على الشعبية أو ادعاءات الأداء.

الخلاصة

Jest وVitest كلاهما قادر على توفير بيئة اختبار قوية، لكن كل واحد منهما يناسب نوعًا مختلفًا من سير العمل.

يوفر Jest منظومة اختبار ناضجة ومتكاملة وقاعدة استخدام واسعة، مما يجعله خيارًا ممتازًا للمشاريع القائمة والفرق التي تعتمد عليه بالفعل.

أما Vitest فيوفر بنية أصلية لمنظومة Vite، وواجهات متوافقة مع Jest، ودعمًا حديثًا لـTypeScript وJSX، ووضع مراقبة ذكي، وإمكانية إعادة استخدام إعدادات Vite.

بالنسبة لمشروع جديد يعتمد على Vite، يمكن أن يكون Vitest خيارًا طبيعيًا للبدء. أما المشروع المستقر الذي يعتمد بشكل كبير على Jest، فيجب ألا ينتقل إلى Vitest إلا إذا كانت هناك فوائد واضحة وقابلة للقياس.

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

المصادر

تم إعداد المعلومات التقنية في هذا المقال بالاعتماد على وثائق Jest الرسمية ووثائق Vitest الرسمية، بما في ذلك أدلة الميزات والانتقال من Jest إلى Vitest.