يبدو أن Vitest سريع جزئيًا لأنه يشارك نفس افتراضات النظام البيئي مثل Vite. هذا الأمر أكثر أهمية من لقطات المعايير. عندما يتفق أداة البناء وعوامل تشغيل الاختبارات على ESM، وحل الوحدات، والتحويلات، وراحة المطور، يكون لدى المشروع بأكمله احتكاك أقل مع أدوات البناء.
لهذا السبب، غالبًا ما يشعر Vitest بأنه الخيار الافتراضي الطبيعي في مشاريع الواجهة الأمامية الأحدث.
لماذا تنتقل العملية بسلاسة في كثير من الأحيان
في التطبيقات المعتمدة على Vite، يمكن أن تظل إعدادات الاختبار صغيرة:
import { defineConfig } from "vitest/config";
export default defineConfig({
test: {
environment: "jsdom",
globals: true,
},
});
الجاذبية ليست فقط في السرعة. بل تكمن في أن التطبيق والاختبارات تتحدث نفس لغة الوحدات.
أين لا يزال Jest له معنى
لا يعتبر Jest قديمًا. لا يزال مناسبًا بشكل جيد عندما:
- تعتمد قاعدة التعليمات البرمجية بالفعل على نظامه البيئي
- تم بناء نماذج كبيرة قديمة حوله
- تمتلك الفريق أدوات ناضجة سيكون من المكلف استبدالها
الحركة الخاطئة هي الانتقال لمجرد أن "الجديد يعني الأفضل" دون التحقق من الأدوات والأسلوب الاختباري المحيط.
قاعدة أفضل
إذا كان المشروع يعتمد أولاً على Vite وأولاً على ESM، فإن Vitest عادةً ما يكون الخيار الأنظف. إذا كانت قاعدة التعليمات البرمجية قد استثمرت بعمق بالفعل في عادات Jest وكان الإعداد الحالي مستقرًا، فإن حالة الانتقال تحتاج إلى أن تكون أقوى من مجرد موضة.
قراءة إضافية