وصفة حسب المشروع
Frontend بـ Vite
Vitest + Testing Library + MSW
- Vitest: runner وassertions وmocks
- Testing Library: تعامل المستخدم مع الـ UI
- MSW: responses من الـ API
Node API حديثة
Vitest + SuperTest
- Vitest: تشغيل واختبارات الوحدات
- SuperTest: routes والـ middleware
- test database أو adapters حسب المطلوب
Node stack مرنة
Mocha + Chai + Sinon + SuperTest
- Mocha يشغّل
- Chai يقارن
- Sinon للـ doubles
- SuperTest للـ HTTP
مشروع Jest قائم
Jest + MSW أو SuperTest
متضفش Sinon غالبًا؛ Jest عنده mocks. اختار MSW للـ outbound requests وSuperTest للـ inbound API.
SuperTest وMSW في نفس backend؟
آه، لأنهم على ناحيتين مختلفتين:
SuperTestيبعت request للـ app
Your APIroute + service
MSWيعترض outbound HTTP
Payment APIمش هنتصل بيها
مثال: تختبر POST /checkout بـ SuperTest، والـ route جوه التطبيق تحاول تكلم payment provider. MSW يعترض اتصال الـ provider ويرجع success أو timeout.
إمتى الأداة تبقى زيادة؟
- Chai مع Jest/Vitest: غالبًا تكرار لأن
expectموجودة. - Sinon مع Jest/Vitest: غالبًا تكرار لأن
jestوviعندهم spies/mocks/timers. - SuperTest لاختبار دالة pure: مستوى HTTP زيادة بلا فايدة.
- MSW لدالة واخدة callback واضح: fake function أبسط.
- Jest وVitest سوا في نفس package: migration مؤقتة، مش نهاية مريحة.
متبدأش بالـ mocks
ابدأ باختبار behavior حقيقي. لما تلاقي boundary بطيئة أو غير مستقرة أو مكلفة — database، email، payment، clock — اختار أضيق double يحلها.
أحسن stack مش أكتر stack. هي أقل أدوات تديك ثقة في السلوك المهم.خلّصت الفصل لما
🧠 اختبر نفسك
١) React على Vite بيجيب user من API. Stack بداية مناسب؟
Vitest + Testing Library + MSW.
٢) Express route بتكلم payment API. ينفع SuperTest وMSW مع بعض؟
آه. SuperTest يبعت للـ route، وMSW يعترض الطلب الخارج للـ payment provider.
٣) مشروع Jest مستقر. أنقله Vitest فورًا؟
لأ. حدد مكسب قابل للقياس وتكلفة الهجرة وفروق الـ mocks والـ transforms الأول.