Jest: اختبارات التفاعل البطيء

مرحبا تايرون. حدثت هذه المشكلة مع أكثر من 20 ثانية لملف واحد :)
الشيء هو أنني قمت بتكوينه لتشغيل "jest" فقط في الدليل الجذر. وهناك الكثير من الكتب الفرعية التي كان Jest يبحث عنها لإجراء الاختبارات. تم تقليل تحديد مسار الاختبارات هذا الوقت أكثر من 10 مرات الآن. ولدي أيضًا معالج قهوة أولي. في package.json
"نصوص": {
....
"اختبار": "jest path / to / modules / to / test"
}

راجع للشغل ، هل تقوم بمعالجة القهوة أم ماذا؟ :)

شكرا لرجوعك إليgothy. أنا أستخدم JS العادي مع JSX. أقوم فقط بإجراء اختباراتي من خلال المعالج الأولي لـ JSX مثل المثال (https://github.com/facebook/jest/tree/master/examples/react). يستغرق المثال أيضًا حوالي 2.5 - 3 ثوانٍ للتشغيل. يستغرق مثال jQuery أقل من ثانية. هل من المفترض أن يستغرق المعالج الأولي JSX وقتًا طويلاً عند معالجة ملفات JSX؟

اختبار رد الفعل

اختبار jQuery

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

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

أنا بالتأكيد أختبر أيضًا اختبارات بطيئة بدافع: :(

أنا أعاني من نفس الشيء. لا أعتقد أن الأمر يتعلق بالمعالجة المسبقة (معالجة JSX على هذا الملف الصغير سريعة). لقد علقت على جميع الكود في اختبار المثال باستثناء إحدى عبارات الطلب التالية ولا يزال الاختبار يستغرق 4 ثوانٍ. بمجرد أن أعلق عليهم ، يستغرق الاختبار 0.1 ثانية. لقد أجريت القليل من البحث ويبدو أن HasteModuleLoader مضطر إلى معالجة 490 حزمة مطلوبة (_shouldMock ()) وليس السخرية منها عندما تحتاج إلى رد الفعل / الإضافات.

var React = require('react/addons');

أو

var CheckboxWithLabel = require('../CheckboxWithLabel.js');

قمت بإزالة var React = require('react/addons'); وما زلت أشغل الملفات من خلال المعالج المسبق. ربما حصلت على تحسن 0.2 ثانية. إذا قمت بإزالة المعالج ، أحصل على النتائج التالية:

مع المعالج الأولي JSX

بدون معالج JSX

أنا أفضل Mocha على Jasmine وقررت إعداد ملف gulpfile الذي من شأنه بناء مكون التفاعل ثم تشغيله من خلال مجموعة اختبار mocha (المقتطف أدناه).

function buildScript(file, watch) {
  var bundler = browserify(file);
  var stream;
  bundler.transform(reactify);
  stream = bundler.bundle();
  return stream.on('error', handleErrors)
  .pipe(source(file))
  .pipe(gulp.dest(buildDir + '/'))
  .pipe(mocha({ reporter: 'list' }));
}

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

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

في كلتا الحالتين ، أحتاج حقًا إلى أن تكون اختباراتي سريعة لسير العمل الخاص بي. ما زلت بحاجة إلى معرفة كيفية تشغيل مجموعة واحدة على الأقل. في الياسمين يمكنني استخدام "ddescribe" أو "iit" بدلاً من "description" و "it" لإجراء اختبار أو مجموعة واحدة. الدعابة لطيفة جدًا ، أنا فقط بحاجة إلى سير عمل سريع الآن.

var React = require('react');

var CheckboxWithLabel = React.createClass({displayName: 'CheckboxWithLabel',
    getInitialState: function() {
        return { isChecked: false };
    },
    onChange: function() {
        this.setState({isChecked: !this.state.isChecked});
    },
    render: function() {
        return (
            React.DOM.label(null,
                React.DOM.input(
                    {type:"checkbox",
                        checked:this.state.isChecked,
                        onChange:this.onChange}
                ),
                this.state.isChecked ? this.props.labelOn : this.props.labelOff
            )
            );
    }
});

module.exports = CheckboxWithLabel; 

jeffchan كان على حق. يتم تشغيل جميع التعليمات البرمجية المطلوبة من خلال المعالج المسبق ، وليس فقط ملفات JSX.

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

gulp jest --tests "Checkbox*,*Form*"

ستراقب Watchify بعد ذلك أي تغييرات تعتمد عليها هذه الاختبارات ، ثم تقوم فقط بمعالجة التغييرات ثم إجراء الاختبارات التي أعمل معها فقط.

iamrandys أنا أتفق معك 100٪. إن Jest و React رائعتان ، لكن تجميع JSX في JS يعد عائقًا كبيرًا. هل ترغب فقط في معرفة كيفية حل Gulp لمشكلة تشغيل الملفات المطلوبة (غير JSX) من خلال المعالج الأولي لـ JSX؟ هل تقترح شيئًا مثل ما يلي - http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ؟

نعم ، أفكر في نوع من طبقات التخزين المؤقت مع إضافة gulp
يعمل على

في 11 أغسطس 2014 08:35 ، كتب Tyrone Avnit [email protected] :

iamrandys https://github.com/iamrandys أنا أتفق معك 100٪. دعابة و
رد الفعل رائع ، لكن تجميع JSX في JS يعد عائقًا كبيرًا. مجرد
من الغريب كيف سيحل Gulp مشكلة الحصول على الملفات المطلوبة (غير
JSX) يتم تشغيله من خلال المعالج الأولي لـ JSX؟ هل تقترح شيئا
مثل ما يلي؟ -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

بالضبط ، استخدام البلع و watchify سريع بشكل مثير للدهشة مع التفاعل. رمي في
gulp-Livereload لتحديث متصفحك بعد كل تغيير ويكون لديك ملف
بيئة تطوير مذهلة. أنت تقوم بأي تغيير ، احفظ وأنت تقريبًا
شاهد على الفور التغييرات في جميع المتصفحات المفتوحة وجميع الأجهزة. الآن أنا
فقط بحاجة إلى نفس الشيء بالنسبة لي TDD.

الأمر يتعلق بهذا الأمر ، ولكن استخدم رد الفعل بدلاً من hbsfy.
https://gist.github.com/benhowdle89/9533185

يوم الإثنين ، 11 آب (أغسطس) 2014 الساعة 2:35 صباحًا ، Tyrone Avnit [email protected]
كتب:

iamrandys https://github.com/iamrandys أنا أتفق معك 100٪. دعابة و
رد الفعل رائع ، لكن تجميع JSX في JS يعد عائقًا كبيرًا. مجرد
من الغريب كيف سيحل Gulp مشكلة الحصول على الملفات المطلوبة (غير
JSX) يتم تشغيله من خلال المعالج الأولي لـ JSX؟ هل تقترح شيئا
مثل ما يلي؟ -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

شكراiamrandys. تم تطوير نموذج مرجعي سريع

في كلتا الحالتين ، أحتاج حقًا إلى أن تكون اختباراتي سريعة لسير العمل الخاص بي. ما زلت بحاجة إلى معرفة كيفية تشغيل مجموعة واحدة على الأقل. في الياسمين يمكنني استخدام "ddescribe" أو "iit" بدلاً من "description" و "it" لإجراء اختبار أو مجموعة واحدة. الدعابة لطيفة جدًا ، أنا فقط بحاجة إلى سير عمل سريع الآن.

يمكنك بالتأكيد كتابة it.only وأعتقد أنه يمكنك عمل describe.only أيضًا.

تقوم Karma بما تريده بالضبط وكل ما عليك فعله هو إضافة ملف
karma.conf إلى مشروعك. لم أدرك أن الكارما أيدت رد الفعل
و browserify. يمكنك الآن اختبار جميع المستعرضات الخاصة بك في نفس الوقت.
لقد أنشأت علاقات عامة لمشروعك المعياري.

https://github.com/iamrandys/react-component-boilerplate/tree/karma

ما عليك سوى تشغيل "اختبار npm" وسيقوم karma بتشغيل المستعرضات الخاصة بك وسيراقبها
التغييرات.

يوم الثلاثاء ، 12 أغسطس 2014 الساعة 10:35 صباحًا ، Tyrone Avnit [email protected]
كتب:

شكرا iamrandys https://github.com/iamrandys. طور ملف
تفاعل-مكون-مرجل
https://github.com/TYRONEMICHAEL/react-component-boilerplate الذي يستخدم
موكا وتشاي (يمكن استبدال الياسمين بسهولة). الاختبارات للغاية
سريع وتحصل على فائدة إضافية من Livereload. استخدم كما يحلو لك.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51931532.

استخدم preprocessor.js التالي لتجنب تحويل JSX للملفات غير JSX. كما هو ، فإنه يعالج فقط ملفات .jsx التي تحتوي على بادئة /** @jsx . إذا كنت تريد JSX-transform .js files ، فما عليك سوى إزالة الجزء الأول من شرط if قبل || (بحيث يبقى شرط src.slice ... ).

// from http://facebook.github.io/jest/docs/tutorial-react.html
var ReactTools = require('react-tools');
var MAGIC = "/** @jsx";
module.exports = {
  process: function(src, file) {
    if (!/\.jsx$/.test(file) || src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

لا يزال بطيئا نوعا ما ، على الرغم من.

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

لطيف جدا. أدى هذا إلى تقليل الوقت من 9.3 إلى 4.7 ثانية. هذا لاختبار واحد. سأظل مضطرًا للبقاء مع Karma حيث تكون أسرع بكثير (تستغرق 100 اختبار أقل من ثانية). بالإضافة إلى ذلك ، ستراقب Karma التغييرات أثناء عملك وستختبر الكود الخاص بك في متصفحات متعددة ، لكني أحب الاستهزاء التلقائي لـ Jest. يعد إنشاء جواسيس يدويًا باستخدام إعادة الأسلاك عملاً إضافيًا ، لكن لديك سيطرة كاملة.

نعم ، قد أكون قد أسيء فهمك ، ولكن هذا ما قصدته بشأن إزالة التحقق من .jsx إذا كان لديك ملفات .js مع jsx وتريد اكتشافها استنادًا إلى رأس pragma.

مرسل من الايفون الخاص بي

في 28 أغسطس 2014 ، الساعة 23:45 ، كتب Tyrone Avnit [email protected] :

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

أهلا! أنا أعمل على --watch أجل الدعابة وأحاول عمومًا جعل هذا الأمر أسرع. سوف يقدم تقريرا قريبا.

تستغرق الجولة الأولى بالنسبة لي حوالي 5 ثوانٍ (لدي اختبار واحد فقط ، لقد بدأت للتو). بعد ذلك يستغرق كل شوط إضافي حوالي 1.2-1.5 ثانية.

يبدو أنه تم قضاء قدر مناسب من ذلك الوقت في تحميل ذاكرة التخزين المؤقت السريعة (والتي تعد بالفعل ملف 4 ميغا بالنسبة لمشروعي.

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

يدعم Haste نكهة تنسيق وحدة CommonJS حيث كانت أسماء الوحدات ذات مستوى أعلى وليست نسبية. هذا يعني أننا بحاجة إلى معرفة الوحدات (والاعتمادات) في وقت مبكر قبل تشغيل البرنامج وإلا سيكون من غير الفعال اجتياز نظام الملفات للبحث عن وحدة نمطية لكل require . ومع ذلك ، فإننا ندرك أن معظم الأشخاص يستخدمون تنسيق وحدة نسبيًا (a la node.js) ونريد إزالة التبعية الضمنية على Haste (ما لم يتم توفير خيار) وهذا من شأنه أن يجعله أسرع.

amasad هذا يبدو رائعا. لقد جربت intern.js وأجري اختبارًا منتظمًا للوحدة من سطر cmd إلى النهاية في غضون بضع مللي ثانية. هل تعتقد أن الدعابة يمكن أن تصل إلى هذه السرعة؟ وهل فكرت في استخراج جزء التخزين التلقائي بحيث يمكن استخدامه في أطر أخرى مثل الياسمين أو الموكا؟

لقد وجدت الملفات المطلوبة (خاصة "التفاعل / الإضافات" والوحدة التي يتم اختبارها) مرة واحدة تحت وصف رد الاتصال ، بدلاً من تكرار عمليات الاسترجاعات beforeEach أو it تُحدث فرقًا كبيرًا.

من الواضح أنني أستخدم برنامج coffee-script وليس jsx ، ولكن هذا يوفر كلاً من عمل المعالج المسبق والعمل الدعائي في محاكاة مكالمات require تلقائيًا.

__tests__/login_fields.coffee (3.013s) (أوه!)

describe 'Login Fields', -> 
 beforeEach ->
    {TestUtils} = require('react/addons').addons
    LoginFields = require '../login_fields'
    ...
  it 'should have left animation states defined', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should have a translateX value equal to enterStateStart.left', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call handleLogin on button click or enter press with the entered username and password', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call updateFields on all change events', ->
    {TestUtils} = require('react/addons').addons
    ...

ولكن ، يصبح أسرع بكثير مع ...
__tests__/login_fields.coffee (0.604s) (ليس سيئًا)

describe 'Login Fields', ->
  {TestUtils} = require('react/addons').addons
  LoginFields = require '../login_fields'
  # require other repeatedly needed modules here as well

  beforeEach ->
    # now you can use TestUtils to renderIntoDocument LoginFields here

  it 'should have left animation states defined', ->
    # and use TestUtils here
  ...

يبلغ طول اختباراتي 14 ثانية ، حتى بعد استخدام جميع التحسينات الموصى بها حتى الآن. حتى مع 16 جيجا رام و SSD. Jest غير قابل للاستخدام تمامًا في حالته الحالية. آسف ، التحول إلى الكارما.

لقد حققت نجاحًا كبيرًا مع karma و mocha و chai و sinon و rebireify و aliasify. يتم إجراء أكثر من 300 اختبار في نصف ثانية. أفضل ما في الأمر أن رد الفعل مذهل !!!!! الفريق يحبها وقد عمل على تطوير بعض الأشياء الجيدة حقًا معها. إنه نظيف للغاية ويمكن صيانته. فرق كبير عن أي شيء استخدمناه من قبل.

فقط ركضت في هذا بنفسي. تعمل الاختبارات ببطء _REALLY_. تكمن مشكلة الاختبارات البطيئة في قيام المطورين بتعطيلها أو تشغيلها لجزء من الوقت فقط. أي فكرة ما يسبب هذا؟ كيف يمكنني أن أقدم المساعدة؟

كانت لدي هذه المشكلة بالضبط - استغرقت الاختبارات حوالي 17 ثانية للتشغيل في البداية ، ثم 4 ثوانٍ بعد التخزين المؤقت. اتضح أن دليل البناء الخاص بي والوحدات النمطية الخارجية لم يتم استبعادها بشكل صحيح. يؤدي تعيين خيار التهيئة testPathDirs للإشارة إلى الدليل المصدر إلى تقليل أوقات التشغيل إلى 0.5 ثانية.

نجح هذا بالنسبة لي باستخدام React v0.12 +:

var ReactTools = require('react-tools');


module.exports = {
  process: function(src, file) {
    if(!file.match(/\.react\.js$/)) return src;

    return ReactTools.transform(src);
  }
};

بدأت للتو في استخدام Jest أيضًا - فقط اختبر وحدات JavaScript العادية (بدون JSX / React) و Jest بطيئة سيئة. أحب فكرة الاختبارات المضمنة والسخرية المضمنة ، لكنها بطيئة للغاية لدرجة تجعلني أفتقد موكا. لست متأكدًا من الجاني ... إنه لا يبحث في شجرة الدليل الذي يسبب السرعة البطيئة. إذا حددت الملف مباشرة ، فسيظل بطيئًا للغاية.

أي أفكار على الأقل حول سبب البطء؟ (أنا لا أستخدم JSX / CoffeeScript ؛ تم إيقاف تشغيل السخرية التلقائية)

لم ينجح المثال الأصلي معي أبدًا لأن الحجة الأولى كانت دائمًا صحيحة.

var ReactTools = require('react-tools');
var MAGIC = "/** <strong i="6">@jsx</strong> ";
module.exports = {
  process: function(src, file) {
    if (src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

culshawhaihappen شكرًا على الحلول واختصر 10s + الاختبارات إلى 2+. جعلتني هذه الحلول أعتقد أنه ربما يجب علينا استخدام الامتداد _.jsx / _. رد فعل. js لملفات التفاعل الخاصة بنا ، أعتقد أنه قد يساعد أيضًا عند استخدام إعادة التفعيل.

لأكون صادقًا في تجربة Grunt ، كنت ما زلت أتلقى أوقاتًا تزيد عن 20 عامًا
تفاعل باستخدام الكارما وإجمالي الوقت حوالي +4/5 ثانية.

كل ذلك داخل جهاز VM بالرغم من ذلك

فقط للإبلاغ عن هذا. لقد قمنا باختبار التفاعل مع Karma / Mocha ونقترب من 700 اختبار ويستغرق تشغيل جميع الاختبارات حوالي 4 ثوانٍ. علينا أن نجرب السخائر ، لكن الأمر يستحق ذلك. رد الفعل كان مذهلاً. لا تشوبه شائبة ومستقرة بشكل منعش. مغير اللعبة! لم يتمكن فريقنا من التصوير باستخدام أي شيء آخر.

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

يوم الخميس ، 5 شباط (فبراير) 2015 الساعة 12:17 ظهرًا ، جيل بيرمان [email protected]
كتب:

iamrandys https://github.com/iamrandys هل تمانع في التوضيح
مزيد من التفاصيل كيف تمكنت من جعل الدعابة بهذه السرعة؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/facebook/jest/issues/116#issuecomment -73097182.

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

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

لدي نفس المشكلة: لقد حصلت على 3 اختبارات فقط في مشروع صغير واستغرقوا 3 ثوان.

هل تحسين الأداء في أي مكان قريب من خريطة طريق المشروع؟

راجع للشغل: لقد وجدت طريقة (مخترقة جدًا) لإعادة تشغيل اختبارات الوحدة للملفات التي تغيرت فقط. هذا يجعلها سريعة مرة أخرى ، حيث عادة ما يكون هناك اختبار واحد فقط للتشغيل. أضعه هنا: https://gist.github.com/mik01aj/fefb7718331e5454b9d1

لم يتم ذكر الدعابة الغريبة في React.js 2015 conf.

يبدو أن testPathDirs هو الجاني. حدد مثل هذا في package.json:

  "jest": {
    "unmockedModulePathPatterns": [
      "./node_modules"
    ],
    "scriptPreprocessor": "./preprocessor.js",
    "testDirectoryName": "tests",
    "testPathDirs": ["tests"]
  }

adjavaherian كن حذرًا مع ذلك إذا كنت تستخدم https://github.com/facebook/jest/issues/176

في الواقع ، توقع أن تنكسر السخرية التلقائية بطرق خفية ومحبطة إذا كان testPathDirs الخاص بك لا يغطي تبعياتك.

تجعلني هذه المخاوف أعتقد أننا قد نفعل شيئًا خاطئًا في إعداد الاختبار لدينا. قد أكون مخطئًا هنا ، ولكن على حد علمي ، فنحن جميعًا نستخدم أشياء مثل: var component = React.createFactory(require("component/path")) جنبًا إلى جنب مع الوحدات النمطية الأخرى المطلوبة قبل كل اختبار. بالتأكيد هذا لا يجب أن يكون ضروريًا لجميع الاختبارات. أعني أن المصنع يجب أن ينتج مكونًا جديدًا في كل مرة. لو كنت تحريك تتطلب خارج beforeEach كتلة اختبار يزيد من سرعة 10X. لسوء الحظ ، في هذه الحالة ، تفشل بعض الاختبارات بشكل غريب ولا أعرف السبب.

لست متأكدا إذا كان ذلك يساعد. أفكار؟

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

اهلا ياجماعة،

انا لدى نفس المشكله. لدي حتى بعض حالات الاختبار التي تستغرق حوالي دقيقة واحدة للتشغيل :(

لا أعرف من أين أبدأ في تحديد ملف تعريف لمشكلة الأداء ، أي تلميح؟

تحديث

لقد أصلحت هذه المشكلة التي ظهرت فقط في بيئة الجهاز الظاهري (راجع: http://stackoverflow.com/a/13703132). لا تزال الاختبارات الآن أبطأ مما كنت أتوقعه ولكنها أسرع بكثير مما كانت عليه قبل الإصلاح المتشرد (60 ثانية -> 6 ثوانٍ لبدلة الاختبار الخاصة بي)

إذا كانت السرعة لا تزال تمثل مشكلة ، أقترح الانتقال إلى Mocha. لقد حققنا الكثير من النجاح مع هذه الشوكة ، والتي تشرح كيفية إعداد الاختبارات لعمليات نشر React البسيطة إلى المعقدة. https://github.com/adjavaherian/mocha-react نجري بانتظام أكثر من 100 اختبار في حوالي 3 ثوانٍ.

أوافق موكا هو الطريق للذهاب. ما يصل إلى 900 اختبار تقريبًا وتستغرق حوالي 4 ثوانٍ.

في 23 نيسان (أبريل) 2015 ، الساعة 4:53 مساءً ، كتب أمير دجافاريان إخطارات github.com:

إذا كانت السرعة لا تزال تمثل مشكلة ، أقترح الانتقال إلى Mocha. لقد حققنا الكثير من النجاح مع هذه الشوكة ، والتي تشرح كيفية إعداد الاختبارات لعمليات نشر React البسيطة إلى المعقدة. https://github.com/adjavaherian/mocha-react نجري بانتظام أكثر من 100 اختبار في حوالي 3 ثوانٍ.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

نفس التجربة ، لقد قمت للتو بإعداد Jest باختبار واحد فقط (باستخدام JSX) ويستغرق الأمر حوالي 3 ثوانٍ ، وهذا كثير.

iamrandys هل تمانع في عرض مثال على الإعداد الخاص بك؟ يبدو وكأنه السرد المثالي.

amasad هل هناك خيار مع Jest لإنشاء ذاكرة تخزين مؤقت للملفات المترجمة على غرار ما يسمح به برنامج تحميل babel في خيار cacheDirectory؟ - https://github.com/babel/babel-loader#options

ما يجعل الدعابة بطيئة بالنسبة لي ليس التجميع بل بدء تشغيل عمليات تجمع العمال. اجتازت جميع الاختبارات الخاصة بي أقل من 0.05 ثانية باستثناء الاختبار الأول الذي يستغرق حوالي 4 ثوانٍ.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

songawee لا تريد سوى إرسال PR للحصول عليها كخيار؟ لا أعتقد أنه يجب تشغيله افتراضيًا لأنه من المستحيل أحيانًا معرفة وقت كسر ذاكرة التخزين المؤقت. على سبيل المثال ، إذا قمت بتغيير خيارات المترجم ، فيجب إعادة تعيين ذاكرة التخزين المؤقت. خيار آخر هو أن يكون لديك خيار إعادة تعيين ذاكرة التخزين المؤقت بالإضافة إلى التخزين المؤقت.

doodzik هل أنت متأكد من أنه تجمع العمال وليس node-haste يوضح وقراءة الوحدات؟

amasad ما فعلته هو قياس الوقت الذي jest حتى تكتمل.
وكان node-worker-pool آخر مثال كانت الاختبارات فيه بطيئة.
يمكن أن تكون النتائج التي توصلت إليها مجرد أعراض وليست أصل المشكلة.
لكن لم يكن لدي الوقت الكافي لإعطائها التحليل المناسب.

تبدو اختباراتي حاليًا كما يلي:

اختبارات رد الفعل الخاصة بي بطيئة (تلك الموجودة في مجلد الأمثلة). ما أتحدث عنه هو اختبارات عدم التفاعل.

+1

كذلك هنا. الاختبارات بطيئة للغاية: محبط:

اعتقدت أنني أنا فقط من يواجه المشكلة. إنها المرة الأولى التي أستخدم فيها Jest ولا أحصل على نتيجة اختبار سريعة أيضًا. أتساءل كيف يقوم Facebook بإجراء الاختبار باستخدام Jest؟

سؤالي حول تحسينات Jest على رجال React في جلسة أسئلة وأجوبة في مؤتمر React Europe - https://youtu.be/CRJZBZ_-6hQ؟

تحولت إلى Mocha + Sinon. لم أكن أسعد من قبل.

في 31 أغسطس 2015 الساعة 17:45 ، كتب Alan Rubin [email protected] :

سؤالي حول Jest to the React guys في مؤتمر React Europe سؤال وجواب
الجلسة - https://youtu.be/CRJZBZ_-6hQ؟t=363

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/facebook/jest/issues/116#issuecomment -136394910.

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

لقد قمت بإنشاء بعض تفريغ وحدة المعالجة المركزية باستخدام ملف التعريف v8 (https://github.com/node-inspector/v8-profiler) ووجدت أنه يبدو أن معظم الوقت يقضي في الاستهزاء بالوحدات النمطية. أي يتم قضاء 25٪ من وقت تنفيذ اختبار الوحدة الخاص بي في jest-cli / src / lib / utils.js # runContentWithLocalBindings.

أي تحديثات للأداء؟ التقطت للتو مازحًا باستخدام es6 و babel-jest ، ولكن أجرِ اختبارين بسيطين في أكثر من 10 ثوانٍ :-(
جربت الكثير من الأفكار من هذا الموضوع للإسراع ، لكن لم ينجح شيء ...

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

هل هناك أي مهام يمكن أن يساعد بها المجتمع؟

+1

أكبر مساعدة في الوقت الحالي ستكون في الواقع تحسين التوثيق وموقع الويب وتصفح المشكلات ومساعدة الأشخاص في المصادر المفتوحة.

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

في النهاية وجدنا أن الوحدات النمطية السخرية مكلفة للغاية (انظر تعليقي أعلاه) وتتسبب في غالبية وقت التنفيذ.

Jest مع es6 بالنسبة لي غير قابل للاستخدام تمامًا. يستغرق الأمر أكثر من 10 ثوانٍ لبدء التشغيل ، ثم يستغرق الأمر ثانيتين لتشغيل الاختبار الفردي الذي أجريته في الوقت الحالي. كنت أتوقع الكثير ، أعود إلى الكرمة :(

نحن نعمل حاليًا على استبدال تسرع العقدة بمحلل وحدة جديد ، والذي يجب أن يصلح هذه المشكلة.

تحية للجميع. هل هناك أي أخبار عن هذا الموضوع؟

مرحبًا ، هل Jest مناسب للاختبار بخلاف React؟ هل ترغب في الحصول على معيار مشترك لكل من تطبيقات التفاعل والتطبيقات غير التفاعلية في فريقنا.

Jest هو عداء اختبار عالمي ولا يلزمك بأي حال من الأحوال استخدام React. :) الق نظرة على أحد الأمثلة!

مرحبًا بالجميع ، بعض المعلومات الشيقة الحقيقية هنا. كما أنني أواجه مشكلات مع الاختبارات التي تعمل ببطء أيضًا. لدي حاليًا 13 اختبارًا يستغرق تشغيلها حوالي 15 ثانية.

لقد وجدت أن إضافة "testPathDirs": ["<rootDir>/path/to/tests/"] إلى ملف bund.json يساعد في تحسين وقت بدء التشغيل بشكل كبير.

cpojer هل تلقيت تحديثًا لنا بخصوص محلل الوحدة الجديد والمحسّن؟ آمل حقًا أن يكون هذا هو المفتاح لإجراء الاختبارات بشكل أسرع

هذا العمل يحدث في # 599.

شكرا @ cpojer 😀
إنني أتطلع إلى رؤية Haste2 النهائي

تم إجراء نفس الاختبارات باستخدام mocha في 44 مللي ثانية بالنسبة لي حيث استغرق المزاح 6 ثوانٍ كاملة.

استغرق الأمر حوالي 15 دقيقة لتبديل ملفات الاختبار الستة الأولية باستخدام jest لاستخدام Mocha ، jsdom و sinon .

أخبار سارة للجميع ، أنا أقوم بدمج # 599 اليوم ويجب أن يتخلص من بدء التشغيل البطيء ، أخيرًا.

حسنًا ، يجب إصلاح هذا أخيرًا في Jest 0.9. نأسف لأن هذا استغرق وقتًا طويلاً ولكن كان هناك بعض المهرج في Jest :)

راجع https://github.com/facebook/react/pull/6052 لمعرفة كيفية تسريع اختبارات React نفسها. إذا كنت ترغب في تجربة هذا التحسين ، فاطلع على التعليقات في # 599. تم وضع علامة عليه حاليًا كـ jest-cli@next حتى معرفة ما إذا كان هناك أي أخطاء قد يواجهها الأشخاص في المصدر المفتوح. سأغلق هذه المشكلة كما تم حلها.

npm install jest-cli@next إذا كنت تريد تشغيل هذا الإصدار الجديد (بدلاً من jest@next cpojer)

أوه نعم ، أنا أرتكب هذا الخطأ دائمًا :) لقد قمت بتعديل تعليقي الأصلي.

cpojer بعد الترقية باستخدام npm install jest-cli@next أواجه مشكلات في تحديد dontMock . أعني ، قبل التحديث (باستخدام [email protected]) ، يعمل هذا السطر بشكل صحيح:

jest.dontMock('../../../../fixtures');

ثم بعد التحديث إلى 0.9.0 ، تؤدي نفس المكالمة إلى السخرية من الوحدة

steinbachr التي ربما يجب أن تدخل في قضية منفصلة. سيكون رائعًا إذا كان بإمكانك تقديم repro ، ولم أر هذه المشكلة تظهر في FB!

شكرًا cpojer ، تم إنشاء المشكلة هنا