Jest: धीमी प्रतिक्रिया परीक्षण

हाय टायरन। एक फ़ाइल के लिए 20+ सेकंड के साथ यह समस्या थी :)
बात यह थी कि मैंने रूट निर्देशिका में 'जेस्ट' चलाने के लिए कॉन्फ़िगर किया है। और ऐसे बहुत से उपखंड हैं जिन्हें जेस्ट परीक्षण के लिए जाँच रहा था। परीक्षणों के लिए पथ निर्दिष्ट करना इस बार अब 10 गुना से अधिक कम हो गया है। और मेरे पास एक कॉफी प्रीप्रोसेसर भी है। पैकेज में।json
"स्क्रिप्ट": {
....
"टेस्ट": "जेस्ट पथ/से/मॉड्यूल/से/परीक्षण"
}

BTW, क्या आप कॉफी को प्रीप्रोसेस कर रहे हैं या क्या? :)

मेरे पास वापस आने के लिए धन्यवाद @gothy। मैं JSX के साथ नियमित JS का उपयोग कर रहा हूं। मैं उदाहरण के लिए जेएसएक्स प्रीप्रोसेसर के माध्यम से अपने परीक्षण चला रहा हूं (https://github.com/facebook/jest/tree/master/examples/react)। उदाहरण को चलने में भी लगभग 2.5 - 3 सेकंड का समय लग रहा है। JQuery के उदाहरण में एक सेकंड से भी कम समय लगता है। क्या JSX प्रीप्रोसेसर का मतलब आपकी JSX फ़ाइलों को संसाधित करते समय इतना समय लेना है?

प्रतिक्रिया परीक्षण

jQuery टेस्ट

आह, मैंने इसे JSX के लिए उपयोग नहीं किया। इस प्रोसेसर पर कुछ नहीं कह सकते। शायद यह वास्तव में धीमा है। मुझे पुरानी चीजों के भार के साथ एक वास्तविक परियोजना पर निर्देशिकाओं के साथ मेरी समस्या मिली है :)

मैंने कॉफ़ीस्क्रिप्ट प्रीप्रोसेसर के साथ एक समान समस्या का अनुभव किया। मुझे लगता है कि यहां समस्या यह है कि प्रीप्रोसेसर आपकी निर्भरताओं को भी संसाधित करने का प्रयास करता है। यदि आपको बहुत सी चीजों की आवश्यकता होती है, तो यह धीमा हो जाता है।

मैं निश्चित रूप से जेस्ट के साथ धीमे परीक्षणों का भी अनुभव करता हूं :(

मैं वही अनुभव कर रहा हूं। मुझे नहीं लगता कि इसका प्रीप्रोसेसिंग से कोई लेना-देना है (इस छोटी फ़ाइल पर JSX प्रोसेसिंग तेज़ है)। मैंने उदाहरण परीक्षण में सभी कोड पर टिप्पणी की, सिवाय निम्नलिखित में से किसी एक कथन की आवश्यकता है और परीक्षण में अभी भी 4 सेकंड लगते हैं। जैसे ही मैं उन पर टिप्पणी करता हूं, परीक्षण में 0.1s लगते हैं। मैंने थोड़ी खुदाई की और ऐसा लग रहा है कि HasteModuleLoader को 490 आवश्यक पैकेज (_ shouldMock ()) को संसाधित करना है और जब आपको प्रतिक्रिया / एडऑन की आवश्यकता होती है तो उनका मजाक नहीं उड़ाते।

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

या

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

मैंने निम्नलिखित var React = require('react/addons'); हटा दिया और अभी भी प्रीप्रोसेसर के माध्यम से फाइलें चलाईं। मुझे शायद 0.2 सेकंड का सुधार मिला। अगर मैंने प्रीप्रोसेसर को हटा दिया है, तो मुझे निम्नलिखित परिणाम मिलते हैं:

JSX प्रीप्रोसेसर के साथ

JSX प्रीप्रोसेसर के बिना

मैं जैस्मीन पर मोचा पसंद करता हूं और एक गल्पफाइल स्थापित करने का फैसला करता हूं जो प्रतिक्रिया घटक का निर्माण करेगा और फिर इसे मोचा टेस्ट सूट (नीचे स्निपेट) के माध्यम से चलाएगा।

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 फ़ाइल को रिएक्टिफ़ाइ का उपयोग करके प्रीप्रोसेस करना है, लेकिन धीमे परीक्षणों के लिए चेतावनी संदेश को हटा देता है। तो रनटाइम अभी भी 2 सेकंड से कम समय लेता है, लेकिन वास्तविक परीक्षण लगभग 32ms है। अभी भी तय करना है कि JSX का उपयोग करना इसके लायक है या नहीं।

ओह तुम सही हो। मैंने JSX का उपयोग न करने वाले जेस्ट रिएक्ट उदाहरण का परीक्षण किया और यह करीब 4 सेकंड से नीचे 0.75 सेकंड तक चला गया। मुझे वास्तव में लगता है कि क्या यह JSX का उपयोग करने के लायक है। एक बड़े प्रोजेक्ट पर, जब तक मेरे पास बहुत सारे अलग-अलग पैकेज नहीं होंगे, तब तक यह बहुत तेज़ी से धीमा होने वाला है। मुझे आश्चर्य है कि क्या प्रीप्रोसेसर सभी 490 पर चलाया जाता है, न कि केवल एक फ़ाइल की। उस साधारण घटक के लिए 3 सेकंड लगने का कोई तरीका नहीं है।

किसी भी तरह से, मुझे वास्तव में अपने वर्कफ़्लो के लिए तेज़ होने के लिए वास्तव में मेरे परीक्षणों की आवश्यकता है। मुझे अभी भी यह पता लगाने की जरूरत है कि कम से कम एक सूट कैसे चलाया जाए। चमेली में मैं एक परीक्षण या सूट चलाने के लिए "वर्णन" और "इसे" के बजाय "ddescribe" या "iit" का उपयोग कर सकता था। जेस्ट बहुत अच्छा है, मुझे अभी एक तेज़ वर्कफ़्लो की आवश्यकता है।

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; 

@ जेफचन सही था। सभी आवश्यक कोड प्रीप्रोसेसर के माध्यम से चलाए जाते हैं, न कि केवल JSX फाइलें।

ऐसा लगता है कि आपके काम करते समय केवल बदली हुई JSX फ़ाइलों को संसाधित करने के लिए गल्प का उपयोग करना, देखना और प्रतिक्रिया करना सबसे तेज़ समाधान होगा। तब हम केवल उन परीक्षणों को निर्दिष्ट करने में सक्षम होंगे जिन्हें मैं भी चलाना चाहता हूं। इस तरह जेएसएक्स फाइलें केवल एक बार संसाधित हो जाती हैं और मेरे पास नियंत्रण होता है कि कौन से परीक्षण चलाए जाते हैं। ऐसा कुछ परीक्षण वर्कफ़्लो के लिए वाकई अच्छा होगा।

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

Watchify तब किसी भी परिवर्तन के लिए देखेगा जिस पर ये परीक्षण निर्भर करते हैं, और उसके बाद केवल परिवर्तनों को संसाधित करते हैं और फिर केवल उन परीक्षणों को चलाते हैं जिनके साथ मैं काम कर रहा हूं।

@iamrandys मैं http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

हां, मैं गल्प प्लगइन के साथ किसी प्रकार की कैशिंग परत के बारे में सोच रहा हूं
काम पर

11 अगस्त 2014 08:35 को, टाइरोन अवनीट नोटिफिकेशन @github.com ने लिखा:

@iamrandys https://github.com/iamrandys मैं आपसे 100% सहमत हूं। जेस्ट और
प्रतिक्रिया कमाल की है, लेकिन JSX को JS में संकलित करना एक बड़ी बाधा है। अभी - अभी
जिज्ञासु कैसे गुलप आपकी आवश्यक फाइलें रखने की समस्या का समाधान करेगा (नॉन
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।

वास्तव में, गल्प और वॉचिफाई का उपयोग करना प्रतिक्रिया के साथ आश्चर्यजनक रूप से तेज़ है। अंदर फेंके
प्रत्येक परिवर्तन के बाद अपने ब्राउज़र को रीफ्रेश करने के लिए gulp-livereload और आपके पास एक
अद्भुत विकास वातावरण। आप कोई भी बदलाव करते हैं, बचत करते हैं और आप लगभग
अपने सभी खुले ब्राउज़रों और सभी उपकरणों में तुरंत परिवर्तन देखें। अभी मैं
मेरे टीडीडी के लिए बस एक ही चीज़ की ज़रूरत है।

यह इस तरह से है, लेकिन hbsfy के बजाय रिएक्टीफाई का उपयोग करें।
https://gist.github.com/benhowdle89/9533185

सोम, अगस्त 11, 2014 को दोपहर 2:35 बजे, टाइरोन अवनीट नोटिफिकेशन @github.com
लिखा था:

@iamrandys https://github.com/iamrandys मैं आपसे 100% सहमत हूं। जेस्ट और
प्रतिक्रिया कमाल की है, लेकिन JSX को JS में संकलित करना एक बड़ी बाधा है। अभी - अभी
जिज्ञासु कैसे गुलप आपकी आवश्यक फाइलें रखने की समस्या का समाधान करेगा (नॉन
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। एक त्वरित प्रतिक्रिया-घटक-बॉयलरप्लेट विकसित किया जो मोचा और चाई का उपयोग करता है (चमेली को आसानी से प्रतिस्थापित किया जा सकता है)। टेस्ट बहुत जल्दी होते हैं और आपको Livereload का अतिरिक्त लाभ मिलता है। अपनी इच्छानुसार प्रयोग करें।

किसी भी तरह से, मुझे वास्तव में अपने वर्कफ़्लो के लिए तेज़ होने के लिए वास्तव में मेरे परीक्षणों की आवश्यकता है। मुझे अभी भी यह पता लगाने की जरूरत है कि कम से कम एक सूट कैसे चलाया जाए। चमेली में मैं एक परीक्षण या सूट चलाने के लिए "वर्णन" और "इसे" के बजाय "ddescribe" या "iit" का उपयोग कर सकता था। जेस्ट बहुत अच्छा है, मुझे अभी एक तेज़ वर्कफ़्लो की आवश्यकता है।

आप निश्चित रूप से it.only लिख सकते हैं और मेरा मानना ​​है कि आप describe.only भी कर सकते हैं।

कर्म ठीक वही करता है जो आप चाहते हैं और आपको बस इतना करना है a
karma.conf फ़ाइल को अपने प्रोजेक्ट में जोड़ें। मुझे नहीं पता था कि कर्म समर्थित प्रतिक्रिया करें
और ब्राउजराइज करें। अब आप एक ही समय में अपने सभी ब्राउज़रों में परीक्षण कर सकते हैं।
मैंने आपके बॉयलरप्लेट प्रोजेक्ट के लिए एक पीआर बनाया है।

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

बस 'एनपीएम परीक्षण' चलाएं और कर्म आपके ब्राउज़र लॉन्च करेगा और इसके लिए देखेंगे
परिवर्तन।

मंगलवार, 12 अगस्त 2014 को सुबह 10:35 बजे, टाइरोन अवनीट नोटिफिकेशन @github.com
लिखा था:

धन्यवाद @iamrandys https://github.com/iamrandys। एक त्वरित विकसित किया
प्रतिक्रिया-घटक-बॉयलरप्लेट
https://github.com/TYRONEMICHAEL/react-component-boilerplate जो उपयोग करता है
मोचा और चाई (चमेली को आसानी से बदला जा सकता है)। टेस्ट बेहद
जल्दी और आपको Livereload का अतिरिक्त लाभ मिलता है। अपनी इच्छानुसार प्रयोग करें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/facebook/jest/issues/116#issuecomment -51931532।

JSX-ट्रांसफ़ॉर्मिंग गैर-JSX फ़ाइलों से बचने के लिए निम्न प्रीप्रोसेसर.js का उपयोग करें। जैसा कि, यह केवल .jsx फ़ाइलों को संसाधित करता है जिनमें /** @jsx उपसर्ग होता है। यदि आप .js फ़ाइलों को JSX-रूपांतरित करना चाहते हैं, तो || से पहले if-condition के पहले भाग को हटा दें (ताकि केवल 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 कर दिया। यह एकल परीक्षण के लिए है। मुझे अभी भी कर्म के साथ रहना होगा जहाँ यह बहुत तेज़ है (100 परीक्षण एक सेकंड से भी कम समय लेते हैं)। साथ ही, आपके काम करने पर कर्मा परिवर्तनों को देखेगा और आपके कोड का कई ब्राउज़रों में परीक्षण करेगा, लेकिन मुझे जेस्ट का स्वचालित मॉकिंग पसंद है। मैन्युअल रूप से rewireify का उपयोग करके जासूस बनाना अतिरिक्त काम है, लेकिन आपके पास पूर्ण नियंत्रण है।

हाँ, मैं आपको गलत समझ रहा हूँ, लेकिन मेरा मतलब .jsx के लिए चेक को हटाने के बारे में था यदि आपके पास .js फ़ाइलें jsx के साथ हैं और प्राग्मा हेडर के आधार पर पता लगाना चाहते हैं।

मेरे आईफोन से भेजा गया

28 अगस्त 2014 को, 23:45 बजे, टाइरोन एवनीट नोटिफिकेशन @github.com ने लिखा:

दिलचस्प स्निपेट @sqs। अगर मैं गलत हूं, तो मुझे सुधारें, लेकिन क्या इसे अभी भी प्रत्येक फ़ाइल को देखने और जांच करने की आवश्यकता नहीं है कि इसे परिवर्तित करने की आवश्यकता है या नहीं? मुझे निम्नलिखित के साथ बहुत सफलता मिली है - प्रतिक्रिया-घटक-बॉयलरप्लेट। टेस्ट वास्तव में बहुत जल्दी चलते हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

नमस्ते! मैं मजाक के लिए --watch पर काम कर रहा हूं और आम तौर पर इसे तेजी से आगे बढ़ाने की कोशिश कर रहा हूं। जल्द ही वापस रिपोर्ट करेंगे।

मेरे लिए पहले रन में लगभग 5 सेकंड लगते हैं (मेरे पास अभी एक परीक्षण है, मैं अभी शुरुआत कर रहा हूं)। उसके बाद प्रत्येक अतिरिक्त रन में लगभग 1.2-1.5 सेकंड लगते हैं।

ऐसा लगता है कि उस समय की एक सभ्य राशि जल्दबाजी के कैश को लोड करने में खर्च की जाती है (जो कि मेरी परियोजना के लिए पहले से ही 4 मेगा फ़ाइल है।

मैं --watch काम की प्रतीक्षा कर रहा हूं, लेकिन मैं यह भी सोच रहा हूं कि ऐसा क्या हो रहा है जिसके लिए परीक्षण चलाने के लिए 1.2 सेकंड के लोड समय की आवश्यकता है? मुझे इस बारे में कुछ भी नहीं पता कि जल्दबाजी क्या कर रही है और मजाक इसका उपयोग क्यों कर रहा है, इसलिए मैं बहुत अनजान हूं।

कॉमनजेएस मॉड्यूल प्रारूप के स्वाद का समर्थन करता है, मॉड्यूल नाम सापेक्ष के बजाय शीर्ष-स्तर हैं। इसका मतलब है कि हमें प्रोग्राम चलाने से पहले मॉड्यूल (और निर्भरता) को समय से पहले जानना होगा अन्यथा प्रत्येक require पर एक मॉड्यूल की तलाश करने के लिए फाइल सिस्टम को पार करना अविश्वसनीय रूप से अक्षम होगा। हालांकि हम महसूस करते हैं कि अधिकांश लोग सापेक्ष मॉड्यूल प्रारूप (एक ला नोड.जेएस) का उपयोग कर रहे हैं और हम जल्दबाजी पर निहित निर्भरता को हटाना चाहते हैं (जब तक कि कोई विकल्प प्रदान नहीं किया जाता है) और इससे इसे तेज करना चाहिए।

@amasad जो बहुत अच्छा लगता है। मैंने इंटर्न.जेएस की कोशिश की है और यह कुछ एमएस में समाप्त करने के लिए cmd लाइन से एक नियमित इकाई परीक्षण चलाता है। क्या आपको लगता है कि जस्ट इतनी जल्दी पहुंच सकता है? और क्या आपने ऑटोमॉकिंग हिस्से को निकालने पर विचार किया है ताकि यह चमेली या मोचा जैसे अन्य ढांचे में प्रयोग योग्य हो?

मुझे beforeEach या it कॉलबैक में बार-बार की बजाय वर्णन कॉलबैक के तहत फ़ाइलों की आवश्यकता होती है (विशेष रूप से 'प्रतिक्रिया/एडॉन्स' और मॉड्यूल का परीक्षण किया जा रहा है) कॉलबैक एक बड़ा अंतर बनाता है।

जाहिर है, मैं कॉफी-स्क्रिप्ट का उपयोग कर रहा हूं, जेएसएक्स का नहीं, लेकिन यह प्रीप्रोसेसर काम और जेस्ट दोनों को ऑटो मॉक 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 सेकंड लंबे हैं, यहां तक ​​​​कि अब तक अनुशंसित सभी अनुकूलन का उपयोग करने के बाद भी। वो भी 16GB रैम और SSD के साथ। जेस्ट अपनी वर्तमान स्थिति में पूरी तरह से अनुपयोगी है। क्षमा करें, कर्म पर स्विच करना।

मुझे कर्म, मोचा, चाई, सिनॉन, रीवायरिफाई और अलियासिफाई के साथ बड़ी सफलता मिली है। 1/2 सेकंड में 300 से अधिक परीक्षण चलते हैं। सबसे अच्छी प्रतिक्रिया अद्भुत है !!!!! टीम इसे प्यार करती है और इसके साथ कुछ वाकई अच्छी चीजें विकसित कर रही है। यह इतना साफ और रखरखाव योग्य है। हमारे द्वारा उपयोग की गई किसी भी चीज़ से बहुत बड़ा अंतर।

बस खुद इसमें भाग गया। परीक्षण _REALLY_ धीमे चलते हैं। धीमे परीक्षणों के साथ समस्या यह है कि डेवलपर्स उन्हें अक्षम कर देते हैं या उन्हें केवल समय का हिस्सा ही चलाते हैं। यह किस कारण हो रहा है कोई विचार? मैं आपकी कैसे मदद कर सकता हूँ?

मेरे पास यह सटीक मुद्दा था - परीक्षणों को शुरू में चलाने में लगभग 17 सेकंड लगे, और फिर कैशिंग के 4 सेकंड बाद। यह पता चला है कि मेरी बिल्ड निर्देशिका और बाहरी मॉड्यूल को ठीक से बाहर नहीं रखा गया था। स्रोत निर्देशिका को इंगित करने के लिए testPathDirs कॉन्फ़िगरेशन विकल्प सेट करना रनटाइम को 0.5 सेकंड तक कम कर देता है।

इसने मेरे लिए रिएक्ट v0.12+ का उपयोग करके काम किया:

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


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

    return ReactTools.transform(src);
  }
};

बस जेस्ट का उपयोग करना शुरू कर दिया - बस नियमित जावास्क्रिप्ट मॉड्यूल (कोई JSX / प्रतिक्रिया नहीं) का परीक्षण करना और जेस्ट बहुत धीमा है। मुझे इनलाइन टेस्ट और बिल्ट-इन मॉकिंग का विचार पसंद है, लेकिन यह इतना धीमा है कि यह मुझे मोचा की याद दिलाता है। मुझे यकीन नहीं है कि अपराधी क्या है ... यह निर्देशिका पेड़ नहीं खोज रहा है जो धीमी गति का कारण बन रहा है। अगर मैं सीधे फ़ाइल निर्दिष्ट करता हूं, तो यह अभी भी बहुत धीमा है।

कम से कम धीमेपन के कारण पर कोई विचार? (मैं 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);
  }
};

@culshaw @haihappen अच्छे कामकाज के लिए धन्यवाद, 10s+ परीक्षणों को 2+ तक छोटा करें। इस कामकाज ने मुझे यह सोचने पर मजबूर कर दिया कि शायद हमें अपनी प्रतिक्रिया फाइलों के लिए एक्सटेंशन _.jsx/_.react.js का उपयोग करना चाहिए, मुझे लगता है कि यह प्रतिक्रिया का उपयोग करते समय भी मदद कर सकता है।

ग्रंट के माध्यम से ईमानदार होने के लिए मुझे अभी भी +20 का समय मिल रहा था, मिल गया
कर्म के साथ काम करने की प्रतिक्रिया और कुल समय लगभग +4/5 सेकंड है।

हालांकि सभी एक VM के अंदर

बस इस पर वापस रिपोर्ट करने के लिए। हम कर्मा/मोचा के साथ प्रतिक्रिया का परीक्षण कर रहे हैं और हम 700 परीक्षणों के करीब हैं और सभी परीक्षणों को चलाने में लगभग 4 सेकंड लगते हैं। हमें मॉक का प्रबंध करना होगा, लेकिन यह इसके लायक है। प्रतिक्रिया अद्भुत रही है। निर्दोष और ताज़ा रूप से स्थिर। खेल परिवर्तक! हमारी टीम किसी और चीज का उपयोग करके इमेजिंग नहीं कर सकी।

मुझे कभी भी जेस्ट तेज नहीं मिला। मैं मोचा का उपयोग कर रहा हूँ। अगर जेस्ट तेज था, तो I
इसके बजाय इसका इस्तेमाल किया होगा।

गुरु, 5 फरवरी, 2015 को दोपहर 12:17 बजे, गिल बीरमैन नोटिफिकेशन @github.com
लिखा था:

@iamrandys https://github.com/iamrandys क्या आप इसमें समझाना चाहेंगे?
अधिक विस्तार से बताएं कि आपने इतनी तेजी से मजाक कैसे बनाया?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/facebook/jest/issues/116#issuecomment -73097182।

धन्यवाद @iamrandys मैंने अपना "तेज़ होने के लिए मज़ाक कैसे किया?" यह महसूस करने के बाद कि मैंने आपकी पोस्ट को गलत तरीके से पढ़ा था (लेकिन आपने उसी समय जवाब दिया) ... वैसे भी, यह शर्म की बात है, मुझे लगता है कि जेस्ट को अभी भी उत्पादन के उपयोग के लिए तैयार नहीं माना जाना चाहिए।

@haihappen और @darcyadams द्वारा किए गए कामकाज /परिवर्तनों ने मुझे एक परीक्षण के लिए परीक्षण समय को 3,5 सेकंड से लगभग 1 सेकंड तक कम करने में मदद की। यह स्पष्ट स्टार्टअप समय को ध्यान में नहीं रखता है, जो लगभग 1 सेकंड भी लगता है। यह दैनिक कार्य में कुशल होने के लिए बहुत धीमा लगता है, इसलिए मुझे लगता है कि मैं मोचा/कर्म कॉम्बो पर एक नज़र डालेगा। मुझे डिफ़ॉल्ट रूप से हर चीज का मजाक उड़ाने का जेस्ट का दर्शन पसंद है, लेकिन लाभ सिर्फ एटीएम नहीं है।

मुझे एक ही समस्या है: मुझे एक छोटी परियोजना में सिर्फ 3 परीक्षण मिले और उन्हें 3 सेकंड का समय लगा।

क्या परियोजना रोडमैप पर कहीं भी प्रदर्शन में सुधार हो रहा है?

बीटीडब्लू: मुझे केवल बदली गई फाइलों के लिए यूनिट परीक्षणों को फिर से चलाने के लिए एक (सुंदर हैकिश) तरीका मिला। यह उन्हें फिर से बहुत तेज़ बनाता है, क्योंकि आमतौर पर चलाने के लिए केवल एक ही परीक्षण होता है। मैंने इसे यहां रखा है: https://gist.github.com/mik01aj/fefb7718331e5454b9d1

React.js 2015 कॉन्फिडेंस में स्ट्रेंज जेस्ट का उल्लेख नहीं किया गया था।

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")) साथ में अन्य आवश्यक मॉड्यूल से पहले प्रत्येक परीक्षण के भीतर। निश्चित रूप से यह सभी परीक्षणों के लिए आवश्यक नहीं होना चाहिए। मेरा मतलब है कि एक कारखाने को हर बार एक नया घटक तैयार करना चाहिए। यदि मैं आवश्यकता को पहले के बाहर ले जाता हूं तो प्रत्येक ब्लॉक परीक्षण गति 10x बढ़ जाती है। दुर्भाग्य से, उस स्थिति में, कुछ परीक्षण अजीब तरह से विफल हो जाते हैं और मुझे नहीं पता कि क्यों।

सुनिश्चित नहीं है कि यह मदद करता है। विचार?

अच्छा होगा यदि प्रीप्रोसेसिंग समय रिपोर्ट किए गए परीक्षण निष्पादन समय से बाहर रह गया हो। लाल रंग को देखना अनुचित है जब उस काम का बड़ा हिस्सा एक परिवर्तन कदम से आता है।

हाय दोस्तों,

मुझे भी यही तकलीफ़ है। मेरे पास कुछ परीक्षण मामले भी हैं जिन्हें चलाने में लगभग 1 मिनट लगते हैं :(

मुझे नहीं पता कि प्रदर्शन के मुद्दे को कहां से शुरू करना है, कोई संकेत?

अपडेट करें

मैंने इस समस्या को ठीक किया है जो केवल मेरे VM वातावरण में दिखाई देती है (cf: http://stackoverflow.com/a/13703132)। अब परीक्षण अभी भी मेरी अपेक्षा से धीमे हैं लेकिन योनि फिक्स (मेरे परीक्षण सूट के लिए 60 सेकंड -> 6 सेकंड) से पहले की तुलना में तेज़ हैं।

अगर गति अभी भी एक मुद्दा है, तो मैं मोचा जाने का सुझाव देता हूं। हमें इस कांटे के साथ बहुत सफलता मिली है, जो बताता है कि सरल से जटिल रिएक्ट परिनियोजन के लिए परीक्षण कैसे सेट करें। https://github.com/adjavaherian/mocha-react हम नियमित रूप से लगभग 3 सेकंड में 100 से अधिक परीक्षण चलाते हैं।

मैं सहमत हूं कि मोचा जाने का रास्ता है। लगभग 900 परीक्षण तक और इसमें लगभग 4 सेकंड लगते हैं।

23 अप्रैल 2015 को शाम 4:53 बजे, अमीर जावाहेरियन नोटिफिकेशन @github.com ने लिखा:

अगर गति अभी भी एक मुद्दा है, तो मैं मोचा जाने का सुझाव देता हूं। हमें इस कांटे के साथ बहुत सफलता मिली है, जो बताता है कि सरल से जटिल रिएक्ट परिनियोजन के लिए परीक्षण कैसे सेट करें। https://github.com/adjavaherian/mocha-react हम नियमित रूप से लगभग 3 सेकंड में 100 से अधिक परीक्षण चलाते हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

वही अनुभव, मैंने जेस्ट को केवल एक परीक्षण (जेएसएक्स का उपयोग करके) के साथ स्थापित किया है और इसमें लगभग 3 सेकंड लगते हैं, यह बहुत कुछ है।

@iamrandys क्या आपको अपने सेटअप का उदाहरण दिखाने में कोई आपत्ति है? एकदम सही कॉम्बो की तरह लगता है।

@amasad क्या जेस्ट के साथ संकलित फ़ाइलों के लिए कैश बनाने के लिए एक विकल्प है जो बैबेल-लोडर कैशडायरेक्टरी विकल्प में अनुमति देता है? - 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 यह एक विकल्प के रूप में रखने के लिए पीआर नहीं भेजना चाहता है? मुझे नहीं लगता कि हमें इसे डिफ़ॉल्ट रूप से चालू रखना चाहिए क्योंकि कभी-कभी यह जानना असंभव होता है कि कैश को कब तोड़ना है। उदाहरण के लिए, यदि आप अपने कंपाइलर विकल्प बदलते हैं, तो कैशे रीसेट हो जाना चाहिए। एक अन्य विकल्प कैशिंग के अलावा एक रीसेट-कैश विकल्प होना है।

@doodzik क्या आप सुनिश्चित हैं कि यह वर्कर-पूल है, न कि node-haste मॉड्यूल्स को

@amasad मैंने जो किया वह jest को पूरा करने में प्रत्येक चरण को पूरा करने में लगने वाले समय को मापने के लिए था।
और node-worker-pool आखिरी उदाहरण था जहां परीक्षण धीमे थे।
यह हो सकता है कि मेरे निष्कर्ष सिर्फ लक्षण हैं और समस्या की जड़ नहीं हैं।
लेकिन मेरे पास इसका उचित विश्लेषण करने का समय नहीं था।

मेरे परीक्षण वर्तमान में इस तरह दिखते हैं:

मेरे प्रतिक्रिया परीक्षण धीमे हैं (उदाहरण फ़ोल्डर में वाले)। मैं जिस बारे में बात कर रहा हूं वह गैर-प्रतिक्रिया परीक्षण हैं।

+1

मेरा भी यही विचार है। टेस्ट बहुत धीमे होते हैं :निराश:

मैंने सोचा कि यह केवल मैं ही था जिसने इस मुद्दे का सामना किया। यह मेरा पहली बार जेस्ट का उपयोग कर रहा है और मुझे तेजी से परीक्षा परिणाम भी नहीं मिला है। आश्चर्य है कि फेसबुक जेस्ट का उपयोग करके परीक्षण कैसे करता है?

रिएक्ट यूरोप सम्मेलन प्रश्नोत्तर सत्र में रिएक्ट लोगों के लिए जेस्ट सुधार के बारे में मेरा प्रश्न - https://youtu.be/CRJZBZ_-6hQ?t=363

मोचा + सिनॉन पर स्विच किया गया। कभी खुश नहीं रहा।

31 अगस्त 2015 को 17:45 बजे एलन रुबिन नोटिफिकेशन @github.com ने लिखा:

रिएक्ट यूरोप सम्मेलन प्रश्नोत्तर में जेस्ट टू रिएक्ट लोगों के बारे में मेरा प्रश्न
सत्र - 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 और बेबेल-जेस्ट के साथ जेस्ट उठाया, लेकिन> 10 सेकंड में 2 सरल परीक्षण चल रहा है :-(
इस धागे से बहुत सारे विचारों को गति देने की कोशिश की, लेकिन कुछ भी काम नहीं किया ...

हम जल्द ही इस पर ध्यान देंगे। हम अभी जस्ट पर काम के साथ थोड़ा डूबे हुए हैं लेकिन हम इसे और अधिक शानदार बनाने के लिए प्रतिबद्ध हैं।

क्या ऐसे कोई कार्य हैं जिनमें समुदाय मदद कर सकता है?

+1

अभी सबसे बड़ी मदद वास्तव में दस्तावेज़ीकरण, वेबसाइट में सुधार करना और मुद्दों से गुजरना और लोगों को ओपन सोर्स में मदद करना होगा।

बिल्ड पाइपलाइन में अपने जेस्ट परीक्षणों को गति देने के लिए हमने जो एक काम किया है, वह यह था कि हम अपनी सिंगल कोर मशीन को मल्टी कोर मशीन से बदल दें। डिफ़ॉल्ट रूप से जेस्ट उतने ही श्रमिक पैदा करता है जितने हार्डवेयर थ्रेड उपलब्ध होते हैं। यदि यह आपके लिए उपलब्ध नहीं है तो आप मैन्युअल रूप से '-w' (maxWorkers) के साथ खेल सकते हैं। आप सिंगल कोर पर भी स्पीडअप हासिल कर सकते हैं।

अंततः हमने पाया कि मॉकिंग मॉड्यूल बहुत महंगा है (ऊपर मेरी टिप्पणी देखें) और अधिकांश निष्पादन समय का कारण बनता है।

मेरे लिए es6 के साथ जेस्ट पूरी तरह से अनुपयोगी है। इसे शुरू होने में बस 10+ सेकंड लगते हैं, और फिर इस समय मेरे पास मौजूद एकल परीक्षण को चलाने में 2s लगते हैं। मैं बहुत अधिक उम्मीद कर रहा था, कर्म पर वापस जाना :(

हम वर्तमान में नोड-जल्दी को एक नए मॉड्यूल रिज़ॉल्वर के साथ बदलने पर काम कर रहे हैं, जो इस समस्या को ठीक करना चाहिए।

नमस्ते। क्या इस मुद्दे पर कोई खबर है?

नमस्ते, क्या जेस्ट गैर प्रतिक्रिया परीक्षण के लिए उपयुक्त है? हमारी टीम में प्रतिक्रिया और गैर-प्रतिक्रिया दोनों ऐप्स के लिए एक सामान्य मानक रखना चाहते हैं।

जेस्ट एक सार्वभौमिक परीक्षण-धावक है और आपको किसी भी तरह से रिएक्ट का उपयोग करने की आवश्यकता नहीं है। :) बस एक उदाहरण पर एक नज़र डालें!

हाय सब, यहाँ पर कुछ वास्तविक रोचक जानकारी। मैं भी धीमी गति से चल रहे परीक्षणों के साथ समस्याओं का सामना कर रहा हूँ। मेरे पास वर्तमान में 13 परीक्षण हैं, जिन्हें चलाने में ~15 सेकेंड का समय लगता है।

मैंने पाया कि "testPathDirs": ["<rootDir>/path/to/tests/"] को हमारे package.json फ़ाइल में जोड़ने से स्टार्टअप समय में काफी सुधार हुआ है।

@cpojer क्या आपको हमारे लिए नए और बेहतर मॉड्यूल रिज़ॉल्वर के बारे में कोई अपडेट मिला है? मैं वास्तव में उम्मीद कर रहा हूं कि यह बहुत तेजी से परीक्षण चलाने की कुंजी होगी

यह कार्य #599 में हो रहा है।

धन्यवाद @cpojer
मैं समाप्त जल्दबाजी 2 को देखने के लिए उत्सुक हूं

मेरे लिए 44ms में मोचा रन का उपयोग करते हुए वही परीक्षण जहां जेस्ट ने पूरे 6 सेकंड का समय लिया।

jest का उपयोग करके Mocha , jsdom और sinon का उपयोग करके अपनी प्रारंभिक 6 परीक्षण फ़ाइलों को स्विच करने में मुझे लगभग 15 मिनट का समय लगा।

सभी को खुशखबरी, मैं आज #599 का विलय कर रहा हूं और इसे धीमे स्टार्टअप को खत्म करना चाहिए, आखिरकार।

ठीक है, इसे अंततः जेस्ट 0.9 में ठीक किया जाना चाहिए। क्षमा करें कि इसमें इतना समय लगा लेकिन जेस्ट में कुछ मसखरापन था :)

देखें https://github.com/facebook/react/pull/6052 कि कैसे रिएक्ट टेस्ट खुद को तेज किया गया। यदि आप इस सुधार को आजमाना चाहते हैं, तो #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 जो शायद एक अलग मुद्दे में जाना चाहिए। बहुत अच्छा होगा यदि आप एक रेपो प्रदान कर सकते हैं, इस मुद्दे को एफबी पर नहीं देखा है!

धन्यवाद @cpojer , यहां बनाया गया मुद्दा