Jest: Jest أبطأ 3 مرات على جميع أجهزة Windows (Windows 10 والإصدارات الأقدم)

ذات صلة: # 6783

هل هو بطيء في البدء أم في وضع المشاهدة أيضًا؟ إذا كان فقط أثناء بدء التشغيل ، يمكنك محاولة تثبيت watchman ، فمن المفترض أن يساعدك ذلك (https://facebook.github.io/watchman/docs/install.html)

عند إجراء الاختبارات ، يبدو الأمر جيدًا من الآن فصاعدًا (تحرير: في الواقع يكون أبطأ عند إجراء الاختبارات أيضًا. يمر واحدًا تلو الآخر بسرعة 0.5 ثانية بينما يبدو المعيار مثل 0.05
ثانية لكل اختبار)
ومع ذلك ، فهو بطيء في بدء و / أو بدء اختبارات الدعابة (تأخير حوالي 4-6 ثوانٍ ، 4-6x أبطأ من أجهزة Mac)

سأحاول الحارس وأعود إليك

إذا كان بإمكانك استخدام ملف شخصي باستخدام مثال ndb بدء التشغيل ومعرفة ما هو بطيء ، فستكون هذه مساعدة كبيرة أيضًا 🙂

التأخير لا يزال بطيئا حتى مع تثبيت الحارس.
لقد أجريت اختبارًا للتنميط باستخدام ndb لتشغيل "jest --verbose" ، وإليك النتائج:

لقطة شاشة لأول 1.7 ثانية:

لقطة شاشة من 1.8 ثانية إلى 2.7 ثانية

ملف .json وملف .eapsnapshot يتم حفظهما من علامة تبويب الملف الشخصي في ndb بعد التسجيل:

التنميط. zip

pfftdammitchris ما هي حالة
(ملف واحد أم ملفات متعددة)؟ (مشاهدة الوضع أم لا)؟ هل يمكنك تقديم المثال.
لمشكلة وضع مشاهدة ملف واحد => يرجى قراءة تعليقي الأخير في: # 6783

إنه بطيء لكل من الملفات الفردية والمتعددة ، مع أو بدون وضع المشاهدة. إلى حد كبير في كل مرة يتم فيها تشغيل أي اختبار ، يكون هناك تأخير لمدة 3 ثوانٍ في تهيئة الاختبارات ، ويكون إجراء الاختبارات بطيئًا واحدًا تلو الآخر بمقدار 0.3 أو 0.4 أو 0.5 ثانية لكل منهما بينما يقوم المتسابقون الآخرون للاختبار مثل mocha / chai عادةً بالتشغيل فقط كل واحدة وكأنها تبدو وكأنها 0.05 ثانية لكل منهما.

أستخدم المزاح في codeandbox ويبدو أنهم يجرون المزاح على الفور في اختبارات التهيئة / التشغيل ، وشاهدت زملائي في العمل وهم يقومون بتشغيل المزاح على أجهزة Mac الخاصة بهم ويقومون بتشغيلها على الفور كما هو معتاد. إنها مجرد آلات windows بقدر ما أعرف. أستخدم آلة تعمل بنظام windows في العمل ومازحًا يواجه مشكلة بطيئة هناك ، وأستخدم أيضًا آلة windows في المنزل وتستمر المشكلة هنا.

لقد استخدمت --runInBand ولكن يبدو أنه أبطأ قليلاً من اختبارات الوحدة بمقدار 0.2 ثانية إضافية لكل منها ، بناءً على الشعور.

توضيح

لقد استخدمت --runInBand ولكن يبدو أنه أبطأ قليلاً من اختبارات الوحدة بمقدار 0.2 ثانية إضافية لكل منها ، بناءً على الشعور.

=> هل جربت الإصدار 24؟ من الإصدار 23 إلى الإصدار 24 ، ستلاحظ تحسنًا جيدًا في هذا السيناريو فقط:
_ على rerun مع watch وفقط إذا قمت بتشغيل ملف واحد (ليس في التشغيل الأول) _
-> 2 / 3sec انخفاض إلى 0.4 / 0.5sec.
ولكن بالمقارنة مع mac لم أحاول أبدًا ... لذلك ربما لا يزال سيئًا ... حتى مع التحسين الحالي

تضمين التغريدة

1. أنا أعتبر https://github.com/facebook/jest/issues/7110 بمثابة انحدارات سرعة Jest [v22 vs v23] على Windows لجميع السيناريوهات الإشكالية.
   حيث # 6783 واحد منهم

2. يمكنني اعتبار هذه المشكلة على النحو التالي: مشكلة سرعة jest [Mac مقابل Windows] لجميع السيناريوهات الإشكالية.

اهلا جميعا !
لقد تراكمت بطء jest 24 و windows 10 (800s لـ 400 اختبار!). الطريقة الأسرع لتسريع كل هذا هي استخدام wsl بدلاً من powerhell أو cmd. الآن اختباراتي تستغرق 189 ثانية "فقط".

لدينا مجموعة من 144 ملف اختبار مع 1302 اختبارًا تستغرق دقيقة واحدة و 43 ثانية للتشغيل على جهاز Windows 10 build 15063 ، Core i7 بسعة 16 جيجابايت ، وتستغرق 28 ثانية على MAC OS Mojave مع 32 جيجابايت. ينقسم فريق التطوير لدينا بالتساوي بين Windows و Mac والأرقام قابلة للتكرار بشكل كبير.

إليك اختبار بسيط -

it("works", () => {
  expect(1).toEqual(1);
});

أضعه في codeandbox وهو يعمل على الفور إلى حد كبير - https://codesandbox.io/s/4q8l0q52lw

على جهاز Windows الخاص بي على الرغم من أنه يستغرق 4-5 ثوانٍ -

PASS src / index.test.js
v الأعمال (62 مللي ثانية)

مجموعات الاختبار: 1 ناجح ، 1 إجمالي
الاختبارات: 1 ناجح ، 1 إجمالي
لقطات: 0 المجموع
الوقت: 4.158 ثانية
تم تشغيل جميع أجنحة الاختبار.

استغرق الاختبار نفسه 62 مللي ثانية ، لكن بقية مجموعة الاختبار استغرقت 4 ثوانٍ. تستغرق إعادة إجراء الاختبار بالضغط على Enter نفس القدر من الوقت.

اعداداتي -

> npx envinfo --preset jest

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD

لقد جربته مع WSL Ubuntu وحصلت على نفس النتائج (4-5 ثوانٍ) - تلك الإعدادات -

  System:
    OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm

لقد بدأت للتو مع Jest لذا أجر اختبارات بسيطة جدًا ، ويمكن أن تستغرق من 15 إلى 20 ثانية للتشغيل. أود أن أجعلهم يركضون بسرعة - أميل إلى فقدان قطار أفكاري بخلاف ذلك!

bburns قراءة العدد أعلاه

تضمين التغريدة
يمكنك أن تجرب مع micromatch 4 في قرارات الغزل الخاصة بك. لمعرفة ما إذا كان من الأفضل في النوافذ من فضلك؟
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

أنا على جهاز MacBook Pro جديد تمامًا. نظرًا لأن لدي طلابًا على كل من MacOS و Windows 10 ، فقد قررت إضافة قسمين آخرين إلى محرك الأقراص الخاص بي ؛ واحد لنظام التشغيل Windows 10 والآخر للتخزين المشترك باستخدام Tuxera NTFS.

واجهت مشكلة السرعة هذه اليوم أثناء إعداد درس JavaScript يتضمن اختبارات الوحدة. أنا أقوم بالفعل بتشغيل Jest من MacOS ولكن الكود والاختبارات موجودة في قسم NTFS المشترك. حتى مع وضع علامة على جميع الأجنحة كـ describe.skip ، يستغرق Jest أكثر من 10 ثوانٍ ليكتمل ، في وضعي التشغيل الفردي والساعة.

8 أجنحة
42 الاختبارات

لقد قمت بتبديل jest مقابل mocha و chai وعادت عمليات التشغيل إلى ثانية واحدة تقريبًا ووضع مشاهدة 10 مللي ثانية.

لقد قمت بتبديل المزاح بـ mocha و chai وعادت عمليات التشغيل إلى حوالي ثانية واحدة و 10 مللي ثانية في وضع المشاهدة.

في الأساس لم تقرأ رسالتي الأخيرة. لقد أردت أن تروج لـ mocha/chai ... كلنا نعرف هذا ... نحن نحاول إصلاح انحدار المزاح. إما أن تساعد في القيام بذلك [من رسالتي] ...can you try with micromatch 4... أو إبقاء هذه التعليقات عديمة الفائدة خارج الموضوع. آسف أن أكون مباشرًا ولكن في مرحلة ما لا توجد طريقة أخرى لقول ذلك.

nasreddineskandrani أنا أحاول [email protected] ولكن لا يزال

pachumon الإصلاح غير موجود في 24.8.0 بقدر ما فهمت

تحتاج إلى تعيين تبعية واحدة من jest إلى إصدار معين لإزالة مشكلة الأداء (نظريًا) ، سيكون الإصلاح موجودًا افتراضيًا في jest 25 => اقرأ هنا لمعرفة كيف يكتشف مطور هذا https://github.com/ facebook / jest / issues / 7963 # issuecomment -483985345

لتعيين التبعية (micromatch) إلى الإصدار الذي تم فيه الإصلاح => يمكنك التحقق هنا من أنني قمت بعمل مثال في مشروع صغير
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

أضف إلى package.json : (يجب استخدام yarn وليس npm )

...
  "resolutions": {
    "micromatch": "^4.0.0"
  }
...

أتمنى أن يساعدك هذا! وانتظر ردود الفعل

تضخم وقت التشغيل التجريبي أيضًا من حوالي 2.5 دقيقة في 23.6.0 إلى 15 دقيقة تقريبًا في 24.7.1 و 24.8.0. يقوم خادم CI الخاص بنا بتشغيل windows وشهد زيادة كبيرة مماثلة في وقت الإنشاء مع هذه الترقية. لقد جربت تجاوز دقة تبعية micromatch كما هو مذكور أعلاه بواسطة nasreddineskandrani دون جدوى. يُرجى إعلامي إذا كان هناك أي شيء يمكنني القيام به للمساعدة في تشخيص هذا.

TomMahle هذا
في الوقت الحالي ، أظهر مشروع "عينة" بسيط أداءً جيدًا. بعد تحديث micromatch.
لذلك نحن بحاجة إلى مشروع إشكالي حقيقي لتصحيحه ، هل مشروعك خاص؟ أم عامة؟

شكرًا على الاقتراح حول micromatch nasreddineskandrani ، ولكن مثل TomMahle أعلاه ، لا يبدو أن ^4.0.0 يحسن الأداء بالنسبة لي أيضًا. 😢

لقد اكتشفت شيئًا غير تقليديًا واحدًا قد يساعد في تشخيص هذه المشكلة.

لدي القدرة على تشغيل الدعابة إما على نظام windows الأصلي الخاص بي ، في حاوية عامل إرساء مع دليل التطبيق الرئيسي مُثبت من نظام ملفات windows الخاص بي. يبدو أن التشغيل في وضع غير المراقبة له سلوك متطابق تقريبًا في كلا النظامين ، مما قد يشير ، كما أوضحتthebearingedge ، إلى أن المشكلة الأساسية لها علاقة بنظام ملفات NTFS ، نظرًا لأن حاوية عامل الإرساء الخاصة بي تعمل في النهاية على تشغيل كل شيء باستثناء نظام الملفات في لينكس VM.

ومع ذلك ، في وضع الساعة ، تختلف الأمور قليلاً: تعمل النوافذ الأصلية دائمًا ببطء كما هو متوقع ، لكن حاوية عامل الإرساء لا تقوم بإجراء الاختبارات إلا ببطء في التشغيل الأول . بمجرد إخباره بتشغيل أي مجموعة اختبار للمرة الثانية (على سبيل المثال عن طريق الضغط على p وإدخال نمط) ، فإنه يقوم بتشغيل الاختبارات في أقل من ثانية واحدة (القيام بنفس الشيء في النوافذ الأصلية يستغرق 3-4 ثوانٍ). الجانب السلبي الوحيد لاستخدام docker هو أن أحداث تغيير الملف لا يبدو أنها تنتشر من حجم windows الخاص بي إلى docker ، لذلك يجب أن أضغط يدويًا على Enter لإعادة تشغيل الاختبار بدلاً من القيام بذلك تلقائيًا ، ولكن أعتقد أن هذا ليست ذات صلة بالقضية المطروحة.

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

أنتهي من عمل عامل إرساء أقوم به لمواقع الويب الشخصية الخاصة بي -> بعد (خلال أسبوع) سأعود إلى هذا.

تضمين التغريدة
سأحاول أن يكون لديّ ريبو جيثب مع المشكلة التي تصفها.

1. كم عدد الاختبارات التي لديك؟
2. هل تقوم بتمكين وضع dom للاختبارات؟
3. انها رد فعل أو الزاوي؟
   علاوة:
4. هل يمكنك محاولة إعادة إنتاج المشكلة في github repo لتتمكن من تصحيح الأخطاء؟
   يمكنك شوكة لي: https://github.com/nasreddineskandrani/benchmark_jest
   أو
5. ربما جرب الريبو الخاص بي على جهاز الاختبار الخاص بك؟ ونرى النتائج؟ بين 23.6 و 24

اعتقدت أنه قد تم إيلاء اهتمام كافٍ لقائمين على صيانة Micromatch حتى أنه تم تسويتها بالفعل. يعد إجراء اختبارات الدعابة (وبالتالي الكتابة) على النوافذ تجربة غير سارة للغاية في الوقت الحالي.

لقد انتقلت إلى mocha / chai منذ ذلك الحين ولكنني مندهش من استمرار العمل على هذه المشكلة.

توضيح

لقد استخدمت --runInBand ولكن يبدو أنه أبطأ قليلاً من اختبارات الوحدة بمقدار 0.2 ثانية إضافية لكل منها ، بناءً على الشعور.

=> هل جربت الإصدار 24؟ من الإصدار 23 إلى الإصدار 24 ، ستلاحظ تحسنًا جيدًا في هذا السيناريو فقط:
_ على rerun مع watch وفقط إذا قمت بتشغيل ملف واحد (ليس في التشغيل الأول) _
-> 2 / 3sec انخفاض إلى 0.4 / 0.5sec.
ولكن بالمقارنة مع mac لم أحاول أبدًا ... لذلك ربما لا يزال سيئًا ... حتى مع التحسين الحالي

تضمين التغريدة

1. أعتبر # 7110 بمثابة انحدارات سرعة Jest [v22 vs v23] على Windows لجميع السيناريوهات الإشكالية.
   حيث # 6783 واحد منهم

2. يمكنني اعتبار هذه المشكلة على النحو التالي: مشكلة سرعة jest [Mac مقابل Windows] لجميع السيناريوهات الإشكالية.

حاولت مع كلا الإصدارين في ذلك الوقت من هذا المنشور.

لقد أنشأت للتو مشروعًا جديدًا باختبار واحد مع اختبارات دفع مصفوفة بسيطة واستغرق الأمر أكثر من 10 ثوانٍ من البداية إلى النهاية. يستخدم المشروع رد فعل / مكتوبًا ولكن ملف الاختبار ليس ملف مكون رد فعل ولكنه ملف عادي مثل ملف .js. Gif أدناه كمرجع مرئي إذا كان من الأفضل تصور ماهية المشكلة:

لقد لاحظت أنه في المرة الأولى التي أجري فيها الاختبار يظهر أن الاختبار يقدر بـ 9 ثوانٍ. بمجرد اكتماله ، فإنه يعيد الاختبارات بشكل عشوائي مرة ثانية حتى الانتهاء.

عندما التقطت صورة gif أعلاه (التي كانت المرة الثانية هذه المرة) ، انخفض الوقت المقدر قليلاً ولم يتم إعادة المحاولة الثانية. لست متأكدًا مما إذا كان هذا هو السلوك المزاح المتوقع.

إليكم صورة gif لي وأنا أدير Micromatch 4 مع الغزل في مشروع منفصل:

استخدام نظام التشغيل Windows 10 ومواصفات جهاز الكمبيوتر الخاص بي هي:
معالج AMD FX (tm) -8320 ثماني النواة 3.50 جيجاهرتز
16 جيجا رام
إلى x64
SSD

اسمحوا لي أن أشارك التنميط الخاص بي هنا.
المواصفات:

• نظام التشغيل Windows 10 Pro
• العقدة 10.15.3
• Intel Core i7-4702MQ 2.2 جيجا هرتز
• 8 جيجا رام
• إلى x64
• SSD

خطوات:

1. npx create-react-app my-app --typescript
2. تغيير App.test.tsx
3. تشغيل npm test

ملف تعريف وحدة المعالجة المركزية:

CPU-20190801T141211.zip

هل من المتوقع أن يتم قضاء 15 ثانية فقط في إعادة تكوين الوحدات النمطية لمكون React الفردي البسيط والاختبار؟

هل يمكن لشخص يتمتع بخبرة أكبر في توصيف وحدة المعالجة المركزية إلقاء نظرة؟

112 اختبارًا
نوافذ 10
أول تشغيل 507 ثانية
المدى الثاني 23 ثانية
نظام لينكس الفرعي
أول تشغيل 54 ثانية
المدى الثاني 29 ثانية

85 اختبارًا
نوافذ 10
أول مرة 44 ثانية
المدى الثاني 15 ثانية
نظام لينكس الفرعي
أول تشغيل 26 ثانية
المدى الثاني 15 ثانية

Kepro هذه النتائج مع Micromatch 4؟

أفضل الدردشة المباشرة بدلاً من تلقي مليون رسالة هنا ، فقد أصبح من الجحيم متابعة جميع المشكلات المتعلقة بالموضوع نفسه.
يمكنك الانضمام هنا. https://gitter.im/wearefrontend/jest-slow-windows
أنا عليه الآن ...

تم حظر Gitter عبر VPN لشركتي - إذا كان بإمكانك نشر أي تحديثات ذات مغزى هنا فسيكون ذلك مذهلاً <3

لا يزال بإمكانك الاتصال في المنزل للقيام ببعض المصادر المفتوحة: P وتحقق منه
ملاحظة: تستغرق لعبة dota مزيدًا من الوقت للوقوف في قائمة الانتظار الآن يمكنك التحقق من gitter في هذا الوقت ؛)
هذا هو مكانه الآن: nodejs / node # 28946

nasreddineskandrani لقد حصلت علي. لقد طلبت جهاز macbook جديدًا ، لذا سيكون خارج الإجراء مفتوح المصدر حتى يصل. أرفض بالفعل العمل على صندوق Windows السيء في وقت فراغي: د

يبدو أن المشكلة قد انتقلت إلى مجال node / C ++ ، وهو بعيد قليلاً (للغاية) خارج منطقة الراحة الخاصة بي - لكنني سأقوم ببعض الحفر!

مرحبا أي أخبار عن هذا؟

كحل بديل ، يمكنك استخدام --runInBand إذا بدأت اختبارات متعددة. سيستغرق بدء الاختبار الأول وقتًا طويلاً ولكن الاختبارات التالية ستكون سريعة.

استغرق مشروعي 21.803 ثانية لتنفيذ جميع الاختبارات.
الآن مع --runInBand لا يستغرق الأمر سوى 7.412 ثانية

--runInBand بالنسبة لي فقط اجعله أبطأ. 1200 اختبار. بدون runinBand 70 / 50seconds. مع --runInBand لها 90 ثانية في الثانية في أحسن الأحوال
على لينكس مثل 5-8x أسرع

جرب --maxWorkers = 4 إذن.

@ cino893 ، ليس حلاً :) حاول أن تجد الإصلاح ليس حلاً

أي أخبار عن ذلك؟ أنا مكدسة في الإصدار 21 بسبب هذا الخطأ. v22 بطيء و v23 أبطأ.
ألا تعتقدون يا رفاق أنه خطأ ذو أولوية عالية؟

حيث أعمل ، لا نتمتع بحرية اختيار نظام التشغيل ولا تثبيت Ubuntu على Window أو شيء مشابه.

gombek هل حاولت v25؟ قام فريق Jest بإجراء الكثير من التحسينات في الأداء في جميع المجالات.

مرحبًا ، أعتقد أنني سأضيف بعض المعلومات الإضافية إلى هذه المناقشة. تكون Jest بطيئة أيضًا عند تنفيذها داخل حاوية Docker التي تحتوي على كود المصدر والاختبارات المشتركة عبر وحدة التخزين من النظام المضيف (Windows).

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

gombek هل حاولت v25؟ قام فريق Jest بإجراء الكثير من التحسينات في الأداء في جميع المجالات.

أنا أستخدم Jest v25 على windows ولا يزال بطيئًا

pfftdammitchris لقد قارنت مجموعات اختبار معقدة جدًا على نظام التشغيل Mac + Windows وأرى بعض الاختلافات ، بشكل أساسي من ذاكرة التخزين المؤقت الباردة ، يكون Windows أبطأ بشكل ملحوظ ، ولكن بمجرد أن يكون الجو حارًا ، أحصل على أداء مماثل بين الاثنين.

ومع ذلك...

هناك شيء واحد يجب أن تكون حذرًا منه للغاية على نظام التشغيل Windows على وجه الخصوص وهو البرامج المتطفلة على مستوى النواة مثل برامج مكافحة الفيروسات / مراقبي الملفات مثل Carbon Black (أو برامج أخرى لمشاهدة الملفات في الوقت الفعلي). إذا كان لديك شيء مثل هذا ، يمكنك رؤية أداء ضخم عند تشغيل Jest. أنا أتحدث عن أنها تستغرق عشرات الدقائق لإجراء الاختبارات.

عملت في شركة العام الماضي حيث استغرقت مجموعة الاختبار نفسها حوالي 30 ثانية على Macbook Pro و 20 دقيقة على كمبيوتر محمول يعمل بنظام Windows مع تشغيل برامج مراقبة الملفات هذه.

ليس لدي أي فكرة عن السبب ، لكنني سأخاطر بتخمين أن الأمر يتعلق بمقابض الملفات وكيف يستخدم Jest بعض واجهات برمجة تطبيقات نظام ملفات node.js.

لديّ حوالي 20 اختبارًا فقط وقد أخذت للتو بعض التوقيتات مع jest --watch ، سواء في التشغيل الأولي ثم الضغط على Enter لإعادة تشغيلها.

على نظام التشغيل Windows ، استغرق الأمر حوالي 15 ثانية في كلتا المرتين بينما استغرق تشغيل Linux حوالي 5.3 ثانية للتشغيل الأول و 2.3 في عمليات التشغيل اللاحقة.

حاولت استخدام -t = "GARBAGE" للتسبب في تخطي جميع الاختبارات. استغرق لينكس واحد 1.5 ثانية ولكن النوافذ لا تزال تأخذ 13 ، لذلك يبدو لي أنه ليس التشغيل الفعلي للاختبارات هو الذي يستغرق الوقت!

كلا الجهازين يستخدمان أحدث إصدار من العقدة والدعابة ، ولينكس هو في الواقع جهاز افتراضي يعمل داخل نظام التشغيل Windows باستخدام تقنية Hyper-v ، لذا عند تساوي الأشياء الأخرى أتوقع أن يكون Windows أسرع.

لديّ حوالي 20 اختبارًا فقط وقد أخذت للتو بعض التوقيتات مع jest --watch ، سواء في التشغيل الأولي ثم الضغط على Enter لإعادة تشغيلها.

على نظام التشغيل Windows ، استغرق الأمر حوالي 15 ثانية في كلتا المرتين بينما استغرق تشغيل Linux حوالي 5.3 ثانية للتشغيل الأول و 2.3 في عمليات التشغيل اللاحقة.

حاولت استخدام -t = "GARBAGE" للتسبب في تخطي جميع الاختبارات. استغرق لينكس واحد 1.5 ثانية ولكن النوافذ لا تزال تأخذ 13 ، لذلك يبدو لي أنه ليس التشغيل الفعلي للاختبارات هو الذي يستغرق الوقت!

كلا الجهازين يستخدمان أحدث إصدار من العقدة والدعابة ، ولينكس هو في الواقع جهاز افتراضي يعمل داخل نظام التشغيل Windows باستخدام تقنية Hyper-v ، لذا عند تساوي الأشياء الأخرى أتوقع أن يكون Windows أسرع.

نعم. وإذا قمت بتثبيت أكواد المصدر على linux VM من Windows وقمت بإجراء الاختبارات فإنها تصبح بطيئة كما هي في Windows. هذا يعني بقوة أن المشكلة تكمن في منطق معالجة ملف Jest كما ذكرت سابقًا.

نعم. وإذا قمت بتثبيت أكواد المصدر على linux VM من Windows وقمت بإجراء الاختبارات فإنها تصبح بطيئة كما هي في Windows. هذا يعني بقوة أن المشكلة تكمن في منطق معالجة ملف Jest كما ذكرت سابقًا.

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

رأيت تعليقات hevans90 على مراقبي الملفات. ليس لدي أي برنامج مكافحة فيروسات من جهة خارجية مثبت أو مثبت ، ولكن تعطيل الحماية في الوقت الحقيقي المضمنة في Windows لم يحدث فرقًا ملحوظًا.

آمل أن يكون هذا من بعض المساعدة لأي شخص لديه الوقت لمحاولة تصحيحه.

لقد أكدت اليوم أن Windows Defender يحدث فرقًا كبيرًا.
اعتدت أن أحصل على مجموعة من الاستثناءات ، ولكن عندما تلقيت جهاز الكمبيوتر المحمول الأحدث والأسرع ، لم أستطع طوال حياتي معرفة سبب استغراق المزاح أكثر من 10 دقائق لتشغيل ملف واحد.

ثم تذكرت الاستثناءات.
لا يمكنني تحديد الاستثناءات التي تحدث فرقًا بالضبط ، لكنني جعلت العداء ينخفض ​​إلى أقل من 15 ثانية بدلاً من> 10 دقائق

لقد وجدت جوهرًا مع استثناءات ذات صلة (وإن كانت قوية)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
أضفت أيضًا امتدادات الملفات .ts .js .spec.ts .spec.js .tsx

لا يمكنني تحديد الاستثناءات التي تحدث فرقًا بالضبط ، لكنني جعلت العداء ينخفض ​​إلى أقل من 15 ثانية بدلاً من> 10 دقائق

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

لدي دائمًا استثناءات في المكان على أي حال. وفي الواقع ، تقترح IntelliJ Idea تلقائيًا وضع دليل مساحة العمل في استثناءات ويفعل ذلك نيابةً عنك إذا سمحت له (يجب عليك). لذا في حالتي ، فإن البطء ليس بسبب Windows Defender أو أي برنامج فحص فيروسات آخر.

فرق الأداء هو 5-10x مقارنة بجهاز Mac. الكمبيوتر الشخصي هو جهاز سطح مكتب قوي (اقرأ: أسرع بكثير من جهاز Macbook). كل شيء آخر سريع البرق ، فقط Jest يعاني من هذه المشكلة.

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

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

👋 أرى بعض الردود التي تشير إلى أنهم يستخدمون الكتابة المطبوعة مع الدعابة - قد يكون هذا أمرًا يستحق النظر فيه (إذا كنت تستخدم أيضًا ts-jest): https://github.com/kulshekhar/ts-jest/issues/ 908 # issuecomment -484043250

كان التغيير بالنسبة لي ينتقل من الانتظار لمدة 30 دقيقة للمزاح (بدون ذاكرة تخزين مؤقت) إلى بضع ثوانٍ فقط.

ضع في اعتبارك أن تعيين علامة الوحدات المعزولة لن يؤدي إلى فحص النوع لملفات المواصفات (وفقدان بعض الوظائف): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ التكوين / المعزولة للوحدات. md

أنا أنشر هذا هنا فقط لأنه قد يكون مفيدًا لتحديد ما إذا كانت مشكلتك مزحة.

👋 أرى بعض الردود التي تشير إلى أنهم يستخدمون الكتابة المطبوعة مع الدعابة - قد يكون هذا أمرًا يستحق النظر فيه (إذا كنت تستخدم أيضًا ts-jest): kulshekhar / ts-jest # 908 (تعليق)

كان التغيير بالنسبة لي ينتقل من الانتظار لمدة 30 دقيقة للمزاح (بدون ذاكرة تخزين مؤقت) إلى بضع ثوانٍ فقط.

ضع في اعتبارك أن تعيين علامة الوحدات المعزولة لن يؤدي إلى فحص النوع لملفات المواصفات (وفقدان بعض الوظائف): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ التكوين / المعزولة للوحدات. md

أنا أنشر هذا هنا فقط لأنه قد يكون مفيدًا لتحديد ما إذا كانت مشكلتك مزحة.

نقية JavaScript هنا. لدي هذه المشكلة لذا لا علاقة لها بـ TypeScript.

لمعلوماتك: https://github.com/kulshekhar/ts-jest/pull/1549 سيكون في إصدار ألفا من ts-jest (ربما اليوم). أي شخص يستخدم ts-jest ، الرجاء المساعدة في اختبار إصدار ألفا وإعطائنا بعض التعليقات على https://github.com/kulshekhar/ts-jest/issues/1115

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

قمت للتو بإجراء نفس الاختبار على جهاز Mac. يستغرق بدء الاختبار حوالي 1.5 ثانية ، أقل من ثانية واحدة لتشغيل الاختبار.

أيضًا باستخدام JS ، وليس TS هنا.

نقية JavaScript مع Jest أيضًا هنا. لدي كمبيوتر محمول رباعي النواة قوي مع معالجات Intel 10gen وكل شيء آخر سريع للغاية ، ولكن [email protected] يستغرق 2-3 مرات أكثر على Windows مقابل Linux لإجراء بعض الاختبارات الأساسية.

نفس المشكلة ، حوالي 60 ثانية لتشغيل اختباراتي على windows ، ولا يتم عرض أي واجهة مستخدم لأول 45 ثانية أو نحو ذلك. شغلت نفس مجموعة الاختبار الدقيقة على جهاز Linux واستغرق الأمر 8 ثوانٍ للتشغيل حتى الاكتمال.

أدى تعليق

يتبعryanrapini المشورةCellule الصورة (ولكن مرت Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions )، ورأى أن بعض الاختبارات ذهب من 13 ثانية إلى 6، وذلك أساسا نصف. شكر!

هل يرغب أي شخص في المساهمة بقسم يذكر Windows Defender (أو AV بشكل عام؟) في صفحة الأسئلة الشائعة على موقع الويب؟ https://jestjs.io/docs/en/troubleshooting

أستطيع أن أؤكد أن استخدام isolatedModules: true مع ts-jest أحدث فرقًا كبيرًا في بدء التشغيل البارد (~ 10mins => 15sec)
لم أختبر تحسينهم في ألفا لأنني أنتظر # 9457 حتى تتم معالجتي قبل التحديث إلى jest 25

تحية للجميع،

نفس المشكلة هنا ولا يوجد حل يناسبني ...

أقوم بتشغيل بعض التعليمات البرمجية البسيطة جدًا والتي لدي حاليًا بعض الاختبارات.
إنه من "دورة التفاعل المتقدم" لـ Wes Bo.
يقوم بتشغيله على جهاز Mac ، ويحصل على إجابة فورية من جهاز الكمبيوتر الخاص به.

و لي ايضا:

مجموعات الاختبار: تم تخطي 2 ، وتم تخطي 15 ، وإجمالي 15 من 17
الاختبارات: تم تخطي 6 ، اجتياز 37 اجتياز ، إجمالي 43
لقطات: تم تمرير 18 ، المجموع 18
الوقت: 5.869 ثانية
تم تشغيل جميع أجنحة الاختبار.

isolatedModules: true لا يغير شيئًا في حالتي ، ما زلت حوالي 5-6 ثوان.
وعندما أبدأ الاختبار بأي خيار ، يستغرق الأمر من 9 إلى 10 ثوانٍ.

لم تؤدي إضافة مجلد dev الخاص بي إلى استثناءات Defender إلى أي شيء:

مجموعات الاختبار: تم تخطي 2 ، وتم تخطي 15 ، وإجمالي 15 من 17
الاختبارات: تم تخطي 6 ، اجتياز 37 اجتياز ، إجمالي 43
لقطات: تم تمرير 18 ، المجموع 18
الوقت: 5.563 ثانية
تم تشغيل جميع أجنحة الاختبار.

هل هناك أي خيار جيد على Windows؟
هل أحتاج للذهاب إلى wsl2؟

تحية للجميع،

نفس المشكلة هنا ولا يوجد حل يناسبني ...

أقوم بتشغيل بعض التعليمات البرمجية البسيطة جدًا والتي لدي حاليًا بعض الاختبارات.
إنه من "دورة التفاعل المتقدم" لـ Wes Bo.
يقوم بتشغيله على جهاز Mac ، ويحصل على إجابة فورية من جهاز الكمبيوتر الخاص به.

و لي ايضا:

مجموعات الاختبار: تم تخطي 2 ، وتم تخطي 15 ، وإجمالي 15 من 17
الاختبارات: تم تخطي 6 ، اجتياز 37 اجتياز ، إجمالي 43
لقطات: تم تمرير 18 ، المجموع 18
الوقت: 5.869 ثانية
تم تشغيل جميع أجنحة الاختبار.

isolatedModules: true لا يغير شيئًا في حالتي ، ما زلت حوالي 5-6 ثوان.
وعندما أبدأ الاختبار بأي خيار ، يستغرق الأمر من 9 إلى 10 ثوانٍ.

لم تؤدي إضافة مجلد dev الخاص بي إلى استثناءات Defender إلى أي شيء:

مجموعات الاختبار: تم تخطي 2 ، وتم تخطي 15 ، وإجمالي 15 من 17
الاختبارات: تم تخطي 6 ، اجتياز 37 اجتياز ، إجمالي 43
لقطات: تم تمرير 18 ، المجموع 18
الوقت: 5.563 ثانية
تم تشغيل جميع أجنحة الاختبار.

هل هناك أي خيار جيد على Windows؟
هل أحتاج للذهاب إلى wsl2؟

هل يمكنك محاولة تطبيق الحل الخاص بي وإخباري إذا كان يفعل أي شيء؟ (في الواقع حل Cellule ، لكنني فعلت ذلك عبر القائمة بدلاً من تشغيل برنامج نصي)

هل يمكنك محاولة تطبيق الحل الخاص بي وإخباري إذا كان يفعل أي شيء؟ (في الواقع حل Cellule ، لكنني فعلت ذلك عبر القائمة بدلاً من تشغيل برنامج نصي)

كما قلت في رسالتي ، لقد فعلت ذلك بالفعل :)

أعني أنني تابعت ما فعلته ، عبر القائمة وكل شيء.

أواجه هذه المشكلة أيضًا على Windows. الاختبار نفسه يعمل في أقل من ثانية واحدة ولكن الإعداد الإجمالي يستغرق حوالي 15 ثانية للتنفيذ. لقد جربته مع v24 و v26 ، إنه في الواقع أبطأ قليلاً في v26

لم يحالفني الحظ مع أي مما يلي (لم يحسن وقت التنفيذ):

• إضافة --runInBand
• إعداد maxWorkers
• إضافة استثناءات .ts .js .spec.ts .spec.js .tsx إلى Virus and Threat Protection ، كما اقترحه Cellule و alessioalex

نفس المشكلة على Windows هنا مع vanilla javascript بالإضافة إلى مشروع مطبوع جديد. ثانيتان لإجراء 9 اختبارات وحدة تعمل في أقل من 10 مللي ثانية باستخدام المخاوي.

هذا جنون!

ما عليك سوى تثبيت المزاح على مستوى العالم والآن يعمل نفس المشروع بالضبط في 0.9 ثانية بدلاً من 52 (!!!) ثانية!
npm remove jest في المشروع ، إذن
npm install -g jest

بالطبع أود دمج المزاح باعتباره تبعية في المشروع مرة أخرى. اي فكرة لماذا يحدث ذلك؟

هذا جنون!

ما عليك سوى تثبيت المزاح على مستوى العالم والآن يعمل نفس المشروع بالضبط في 0.9 ثانية بدلاً من 52 (!!!) ثانية!
npm remove jest في المشروع ، إذن
npm install -g jest

بالطبع أود دمج المزاح باعتباره تبعية في المشروع مرة أخرى. اي فكرة لماذا يحدث ذلك؟

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

لقد جربت للتو نفس الشيء مثل JPustkuchen & ينتقل الأداء من حوالي 10 ثوانٍ إلى أقل من ثانية واحدة.

لقد استبعدت مجلد مشروعي من Windows Defender ولكن Jest لا يزال يعمل ببطء.

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

أتمنى أن يقر شخص ما على الأقل بأن هذه مشكلة. كما هو الحال الآن ، فإن جهاز سطح المكتب الخاص بي الذي يعمل بنظام التشغيل windows والذي يحتوي على الكثير من الطاقة (اقرأ: أكثر بكثير من جهاز macbook الخاص بزملائي في العمل) أبطأ بحوالي 69 مرة من جهاز macbook عند إجراء الاختبارات! هذا يجبرني عمليًا على عدم لمس رمز الواجهة الأمامية لأنه من غير الفعال بالنسبة لي العمل على تلك الاختبارات بسبب بطء اختبارات Jest. قد نضطر إلى الابتعاد عن Jest إذا لم يتم إصلاح ذلك. كل شيء آخر سريع للغاية ولكن اختبارات Jest بطيئة للغاية. يتم إنفاق الوقت على شيء آخر غير التنفيذ الفعلي للاختبارات ، عندما يتم تنفيذ منطق الاختبار الفعلي ، يتم تنفيذ هذه الاختبارات بسرعة كبيرة.

في ملاحظة أكثر إيجابية ، أود فقط أن أقول إنني مدين لهذا الخطأ بقدر كبير من الامتنان. لقد كانت القشة الأخيرة التي جعلتني أقرر التبديل إلى Linux من أجل سير عمل التطوير الرئيسي الخاص بي ولم أكن أكثر سعادة من قبل. لا أستطيع أن أقول إنني لن أعود أبدًا لأنه في بعض الأحيان يجب أن أعمل على مشاريع قديمة ، ولكن نظرًا لأن ASP.NET الأساسية تعمل عبر الأنظمة الأساسية ، فإن أسباب إعادة التشغيل إلى Windows أصبحت أقل طوال الوقت.

من فضلك @ timrobinson33 دعنا نبقى على الموضوع. لا يوجد سبب يجب أن يكون jest أبطأ 68 مرة من أي بيئة أخرى على Windows ، مع الأخذ في الاعتبار أن Node تعمل بشكل جيد على أي نظام أساسي. قد أضيف أيضًا ، لم أواجه هذه المشكلة مع أي عداء اختبار آخر.

لقد اختبرت مع v26.4.2 في معيار jest github repo الخاص بي.
https://github.com/nasreddineskandrani/benchmark_jest
إصدار العقدة في جهاز الكمبيوتر الخاص بي: v12.13.0

جيد جدًا عندما أقوم بتحديث الاختبار البسيط (انظر لقطة الشاشة)! بالنسبة لي ، فإن المزاح الآن هو الصحيح لاختبار بسيط.
إذا كان لديك مشكلة في عملك. تحتاج إلى محاولة عزل المشكلة نظرًا لأنها بشكل افتراضي جيدة.

empperi هل يمكنك تجربة الريبو المعياري الخاص بي. مثال مع المجلد v26 وأخبرني كم من الوقت يستغرق تشغيل هذا الاختبار في جهازك؟ إذا لم يكن 0.166 مللي ثانية أو حوله ، فستواجه مشكلة من جانبك.

لقد اختبرت مع v26.4.2 في معيار jest github repo الخاص بي.
https://github.com/nasreddineskandrani/benchmark_jest
إصدار العقدة في جهاز الكمبيوتر الخاص بي: v12.13.0

جيد جدًا عندما أقوم بتحديث الاختبار البسيط (انظر لقطة الشاشة)! بالنسبة لي ، فإن المزاح الآن هو الصحيح لاختبار بسيط.
إذا كان لديك مشكلة في عملك. تحتاج إلى محاولة عزل المشكلة نظرًا لأنها بشكل افتراضي جيدة.

empperi هل يمكنك تجربة الريبو المعياري الخاص بي. مثال مع المجلد v26 وأخبرني كم من الوقت يستغرق تشغيل هذا الاختبار في جهازك؟ إذا لم يكن 0.166 مللي ثانية أو حوله ، فستواجه مشكلة من جانبك.

كما هو متوقع ، لا فرق في أداء إعداد الاختبار الخاص بك. يعمل في الواقع أسرع قليلاً من جهاز الكمبيوتر الخاص بك. تم تغيير إعداد الاختبار بحيث يحتوي على 100 ملف اختبار أقل من __tests__ وهذه الملفات تعمل بشكل جيد. نظرًا لأن تطبيقنا يستخدم react-scripts أضفت ذلك أيضًا إلى مثالك للتحقق مما إذا كان ذلك قد يتسبب في المشكلة الفعلية ولكن لا يوجد فرق في الأداء.

ومع ذلك ، حاولت إجراء تلك الاختبارات في WSL2 bash (ضد نظام ملفات NTFS) و boom ، ووقت التنفيذ ما يقرب من 10x إلى Powershell الخام. من المتوقع أن تكون سرعة الإدخال / الإخراج أبطأ على WSL2 مقابل NTFS ولكن بالنظر إلى مدى بساطة هذا الإعداد (فقط 100 ملف اختبار مع اختبار واحد على كل واحد) لا ينبغي أن يؤثر ذلك كثيرًا. كمرجع ، قمت بتنفيذ هذا على WSL2 bash:

time find . -name "*.js" -print | xargs cat
...(file content prints omitted)...
real    0m0.138s
user    0m0.030s
sys     0m0.000s

مما يدل على أنه لا يستغرق أي وقت من الناحية العملية لقراءة نظام الملفات من WSL2. للإشارة إلى أمر مماثل في Powershell:

> Measure-Command { ls *.js | % { cat $_ } }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 49
Ticks             : 499000
TotalDays         : 5,77546296296296E-07
TotalHours        : 1,38611111111111E-05
TotalMinutes      : 0,000831666666666667
TotalSeconds      : 0,0499
TotalMilliseconds : 49,9

مما يدل على أن الأداء على نفس الملعب.

لذلك ، بناءً على هذا ، أود أن أقول إن المشكلة قد تكون ناتجة عن كيفية استخدام Jest للإدخال / الإخراج وهذا يؤثر بطريقة ما على الأداء بشكل كبير في WSL2. عندما يتعلق الأمر بالمشروع الذي يسبب لي مشكلات ، فليس من السهل عدم طلب bash بسبب مشكلات في التعليمات البرمجية والاختبارات (لم أقم بها!). بالنظر إلى حقيقة أن WSL2 تكتسب شعبية ، أود أن أقول إن هذه مشكلة حقيقية يجب النظر فيها.

أتمنى أن يساعدك هذا.

:تعديل:

بدافع الفضول ، قمت بتنفيذ مجموعة الاختبار الخاصة بنا --no-watch لمعرفة ما إذا كانت مشاهدة نظام الملفات عبر WSL2 تؤثر بطريقة ما على الأشياء. الجواب لا ، لا يؤثر ذلك كثيرًا.

يستغرق تشغيل المعيار على جهاز windows الخاص بي حوالي 1.6 ثانية. أنا لا أستخدم WSL.
أنا أستخدم برنامج مكافحة الفيروسات AVG ، لكني أضفت استثناءات لكل من المستودع والعقدة القابلة للتنفيذ.
القرص الصلب الخاص بي هو SSD.

إصدار العقدة هو v12.16.1

يؤدي تحديث الاختبار على الفور إلى تشغيل مراقب الملفات ، لكن الوقت الفعلي الذي يستغرقه تشغيل هذا التحديث يتراوح بين 1 و 2.4 ثانية.

كنت أرغب في اختبار ما إذا كانت البيئة هي المشكلة.

كنت العبث بهذا الريبو: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• أذهب مقابل npm test وتبدأ جميع الاختبارات في وضع المشاهدة.
• أضغط على "p" لإدخال نمط لملف وأكتب "tdd-02". أحصل على 3+ ثوان من وقت التنفيذ.
  

سأكون مندهشا إذا كان كينت سي دودز لديه بيئة فاسدة في مساره الدراسي المدفوع ، ولكن إذا فعل ذلك ، فيمكنك تصحيحه هناك على الأرجح:؟ في مقاطع الفيديو الخاصة به ، يعمل بشكل جيد ، أعتقد أنه يستخدم جهاز Mac.

يجب أن ألاحظ شيئًا غريبًا جدًا لا يمكنني إعادة إنتاجه مرة أخرى - لقد أجريت بعض عمليات إعادة الاختبار المتتالية التي تم تنفيذها لأحد الملفات (tdd-02 ... js) لمدة 0.1 ثانية تقريبًا ، وللملف المجاور له ( tdd-01 ... js) - حوالي 3 ثوانٍ. الرمز هو نفسه تقريبًا ويستخدم نفس التبعيات. لذلك ، قمت بنسخ الكود من ملف سريع التشغيل ولصقه في الملف الذي يعمل ببطء والعكس صحيح. كانت النتائج هي نفسها - ظل الملف البطيء بطيئًا وظل الملف سريع التشغيل سريعًا ، مع تبديل الرموز الفعلية. هذا يصبح مجنونا الآن كلا الملفين يعملان ببطء مرة أخرى (3-6s).

Glinkis هل يمكنك محاولة

SimeonRolev سألقي نظرة على المثال الذي نشرته وأرى نوع الرقم الذي أحصل عليه بنفس الخطوات (النمط ...)
تحديث:
try1: لقد جربته مثلك وحصلت على 6 ثوانٍ عندما جربت خطواتك -> اسقط إلى 3 ثوانٍ عند إعادة تشغيل الاختبار نفسه (اضغط على Enter)
try2: تمت ترقية المزحة إلى 26.4 في Kent repo -> 3 ثوانٍ تقريبًا أول مرة لإعادة التشغيل
try3: لقد أخذت ملف index.spec.js من الريبو التجريبي الخاص بي. وأنا أسقطته إلى كينت ريبو. (حذف جميع ملفات الاختبار الأخرى) -> مفاجأة 2.8 ثانية (SAME JEST 26.4.2 ، نفس الكمبيوتر ، POWERSHELL ، NODE_VERSION إلخ ... كما تم نشر الاختبار أمس هنا)

لا أفهم أن try3 لا يزال => ~ 3 ثوانٍ عند إعادة التشغيل في Kent repo لملفي ولكن في الريبو الخاص بي ، ينخفض ​​إلى 0.300 ثانية عند إعادة التشغيل (بحاجة إلى شخص ما لتصحيح هذا)
تحرير: يجب أن يكون Kent هو الشخص الذي يقوم بفحص هذا: P

يؤدي الضغط على مفتاح الإدخال إلى إجراء الاختبار في حوالي 200 مللي ثانية.

nasreddineskandrani هل

@ kentcdodds هل ستكون بطلنا مرة أخرى؟

SimeonRolev في معياري ، لا أرى نفس المشكلة كما في Kent repo. لديك شيء في كينت ريبو. التي تسبب هذا البطء => خارجها يكون المزاح أسرع.

تتعلق مشكلة github هذه بنوافذ Jest Performance windows مقابل macOS / Linux لأنها لم تصل إلى نفس الأداء. لم ينصوا عليه على ما أعتقد. (الآن أفضل بكثير مما كانت عليه منذ عامين مع jest v23)

مرحبًا ، أواجه نفس المشكلة هنا. لدي آلة ويندوز و WSL. لقد قمت بنسخ ملفات مشروعي إلى WSL لاختبار هذا السلوك. فيما يلي تشغيل نفس الاختبارين الأساسيين:
Windows 10 (إصدار 2004):

WSL 2 (Ubuntu 20.04):

الاختبارات بسيطة للغاية:

تم إنشاء المشروع باستخدام CRA ، لذلك لا يوجد تكوين لفشل الإعدادات ، ولم أضف شيئًا من حيث Jest.
تجري نفس الاختبارات بسرعة مذهلة على المخاوي ، على الفور تقريبًا. أحاول إعداد بيئة اختبار لمشروعنا ، وأود حقًا استخدام Jest ، لكن يبدو أنه كلما أضفت المزيد والمزيد من الاختبارات ، ستكون مجموعة الاختبار أبطأ وأبطأ على ما يبدو. يبدو أن كل اختبار يضيف 0.8 ثانية ، وهو أمر سخيف ، لأنها لا تفعل شيئًا. هناك شيء ما يعبث بتنفيذ الاختبار على النوافذ ، ولا أعرف ماذا.
كانت المشكلة أسوأ ، اختبار واحد سيستغرق حوالي 15 ثانية ، ولكن عندما أضفت --runInBand ، بدا أن الوضع يتحسن قليلاً ، لكنني أعتقد أنه لا يزال غير كافٍ ، مع الأخذ في الاعتبار أن وضع ساعة mocha فوري.

الغزل هو الإصدار 1.22.5 ، جميع تبعيات npm الأخرى (مثل البرامج النصية للتفاعل والتفاعل) هي الأحدث.

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

تحرير: حاولت الضغط على مفتاح الإدخال ، وكانت الاختبارات بنفس سرعة اختبار WSL:

الآن أنا في حيرة من أمري :)

لكن يبدو أن هذا لا يزال بطيئًا للغاية ، حيث يبدو أن كل اختبار يستغرق 0.3 ثانية ، وهو عدد كبير ، مع الأخذ في الاعتبار أنه لا يفعل شيئًا. أتوقع أن تكتمل هذه المجموعة في أقل من 0.1 ثانية.

تحرير 2: عندما أضفت 100 اختبار إلى مجموعة الاختبار الخاصة بي ، استغرق الأمر حوالي 44 ثانية لتشغيلها ، حتى إذا قمت بالضغط على Enter لتشغيلها:

تستغرق مجموعات الاختبار نفسها حوالي 9-10 ثوانٍ على WSL: