Jest: Tes Reaksi Lambat

Hai Tiron. Punya masalah ini dengan 20+ detik untuk satu file :)
Masalahnya adalah saya telah mengonfigurasi untuk menjalankan 'bercanda' di direktori root. Dan ada BANYAK subdir yang diperiksa Jest untuk pengujian. Menentukan jalur untuk pengujian berkurang kali ini lebih dari 10 kali sekarang. Dan saya juga punya preprocessor kopi. Dalam package.json
"skrip": {
....
"test": "jalur lelucon/ke/modul/ke/tes"
}

BTW, kopinya preprocessing atau gimana? :)

Terima kasih telah kembali kepada saya @gothy. Saya menggunakan JS biasa dengan JSX. Saya hanya menjalankan tes saya melalui preprocessor JSX seperti contoh (https://github.com/facebook/jest/tree/master/examples/react). Contoh ini juga membutuhkan waktu sekitar 2,5 - 3 detik untuk dijalankan. Contoh jQuery membutuhkan waktu kurang dari satu detik. Apakah preprocessor JSX dimaksudkan untuk mengambil begitu banyak waktu saat memproses file JSX Anda?

Uji Reaksi

Tes jQuery

Ah, saya tidak menggunakannya untuk BEJ. Tidak bisa mengatakan apa-apa pada prosesor ini. Mungkin sebenarnya lambat. Saya telah menemukan masalah saya dengan direktori pada proyek nyata dengan banyak barang lama :)

Saya mengalami masalah serupa dengan preprosesor Coffeescript. Saya pikir masalahnya di sini adalah bahwa preprocessor mencoba memproses dependensi Anda juga. Jika Anda kebetulan membutuhkan banyak hal, itu melambat.

Saya pasti juga mengalami tes lambat dengan lelucon :(

Saya mengalami hal yang sama. Saya tidak berpikir itu ada hubungannya dengan preprocessing (pemrosesan JSX pada file kecil ini cepat). Saya mengomentari semua kode dalam tes contoh kecuali salah satu dari pernyataan berikut yang memerlukan dan tes masih membutuhkan waktu 4 detik. Segera setelah saya mengomentarinya, tes membutuhkan waktu 0,1 detik. Saya melakukan sedikit penggalian dan sepertinya HasteModuleLoader harus memproses 490 paket yang diperlukan (_shouldMock()) dan tidak mengejeknya ketika Anda memerlukan reaksi/addon.

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

atau

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

Saya menghapus var React = require('react/addons'); dan masih menjalankan file melalui preprocessor. Saya mungkin mendapat peningkatan 0,2 detik. Jika saya menghapus preprocessor, saya mendapatkan hasil berikut:

Dengan praprosesor JSX

Tanpa preprosesor JSX

Saya lebih suka Mocha daripada Jasmine dan memutuskan untuk menyiapkan gulpfile yang akan membangun komponen reaksi kemudian menjalankannya melalui mocha test suite (cuplikan di bawah).

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' }));
}

Itu masih harus memproses file JSX menggunakan reactify, tetapi menghapus pesan peringatan untuk tes yang lambat. Jadi runtime masih membutuhkan waktu kurang dari 2 detik, tetapi pengujian sebenarnya adalah sekitar 32 ms. Masih memutuskan apakah menggunakan JSX layak dilakukan.

Anda benar. Saya menguji contoh reaksi lelucon tidak menggunakan JSX dan itu berubah dari hampir 4 detik menjadi 0,75 detik. Membuat saya benar-benar berpikir apakah layak menggunakan BEJ. Pada proyek besar, itu akan menjadi lambat cukup cepat kecuali saya memiliki banyak paket yang berbeda. Saya ingin tahu apakah praprosesor dijalankan pada semua 490 yang dibutuhkan dan bukan hanya satu file itu. Tidak mungkin dibutuhkan 3 detik untuk komponen sederhana itu.

Either way, saya benar-benar sangat membutuhkan tes saya untuk menjadi cepat untuk alur kerja saya. Saya masih perlu mencari cara untuk setidaknya menjalankan satu suite. Dalam melati saya bisa menggunakan "ddescribe" atau "iit" alih-alih "describe" dan "it" untuk menjalankan satu tes atau suite. Jest sangat bagus, saya hanya butuh alur kerja yang cepat sekarang.

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 benar. Semua kode yang diperlukan dijalankan melalui praprosesor, bukan hanya file JSX.

Sepertinya solusi tercepat adalah menggunakan gulp, watchify dan react untuk hanya memproses file JSX yang diubah saat Anda bekerja. Kami kemudian akan dapat menentukan hanya tes yang ingin saya jalankan juga. Dengan cara ini file JSX hanya diproses sekali dan saya memiliki kendali atas tes mana yang dijalankan. Sesuatu seperti ini akan sangat bagus untuk alur kerja pengujian.

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

Watchify kemudian akan mengawasi setiap perubahan yang bergantung pada tes ini, dan kemudian hanya memproses perubahan dan kemudian hanya menjalankan tes yang sedang saya kerjakan.

@iamrandys Saya 100% setuju dengan Anda. Jest dan React luar biasa, tetapi kompilasi JSX ke dalam JS adalah hambatan besar. Ingin tahu bagaimana Gulp akan memecahkan masalah menjalankan file yang Anda butuhkan (Non JSX) melalui preprosesor JSX? Apakah Anda menyarankan sesuatu seperti berikut - http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

Ya, saya sedang memikirkan semacam lapisan caching dengan plugin gulp di
bekerja pada

Pada 11 Agustus 2014 08:35, Tyrone Avnit [email protected] menulis:

@iamrandys https://github.com/iamrandys Saya 100% setuju dengan Anda. bercanda dan
Bereaksi luar biasa, tetapi kompilasi JSX ke dalam JS adalah hambatan besar. Hanya
penasaran bagaimana Gulp akan memecahkan masalah memiliki file yang Anda butuhkan (Non
JSX) dijalankan melalui preprocessor JSX? Apakah Anda menyarankan sesuatu?
seperti berikut? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Tepatnya, menggunakan gulp dan watchify sangat cepat dengan reaksi. Mengeluarkan
gulp-livereload untuk menyegarkan browser Anda setelah setiap perubahan dan Anda memiliki
lingkungan pengembangan yang luar biasa. Anda membuat perubahan apa pun, simpan dan Anda hampir
langsung melihat perubahan di semua browser terbuka dan semua perangkat Anda. Sekarang saya
hanya perlu hal yang sama untuk TDD saya.

Kira-kira seperti ini, tetapi gunakan reactify alih-alih hbsfy.
https://Gist.github.com/benhowdle89/9533185

Pada Mon, 11 Agustus 2014 di 02:35, Tyrone Avnit [email protected]
menulis:

@iamrandys https://github.com/iamrandys Saya 100% setuju dengan Anda. bercanda dan
Bereaksi luar biasa, tetapi kompilasi JSX ke dalam JS adalah hambatan besar. Hanya
penasaran bagaimana Gulp akan memecahkan masalah memiliki file yang Anda butuhkan (Non
JSX) dijalankan melalui preprocessor JSX? Apakah Anda menyarankan sesuatu?
seperti berikut? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Terima kasih @iamrandys. Mengembangkan boilerplate komponen reaksi cepat yang menggunakan Mocha dan Chai (Jasmine dapat dengan mudah diganti). Tes sangat cepat dan Anda mendapatkan manfaat tambahan dari Livereload. Gunakan sesuai keinginan.

Either way, saya benar-benar sangat membutuhkan tes saya untuk menjadi cepat untuk alur kerja saya. Saya masih perlu mencari cara untuk setidaknya menjalankan satu suite. Dalam melati saya bisa menggunakan "ddescribe" atau "iit" alih-alih "describe" dan "it" untuk menjalankan satu tes atau suite. Jest sangat bagus, saya hanya butuh alur kerja yang cepat sekarang.

Anda pasti bisa menulis it.only dan saya yakin Anda juga bisa menulis describe.only .

Karma melakukan apa yang Anda inginkan dan yang harus Anda lakukan hanyalah menambahkan
file karma.conf ke proyek Anda. Saya tidak menyadari karma yang didukung bereaksi
dan browserify. Sekarang Anda dapat menguji di semua browser Anda secara bersamaan.
Saya membuat PR untuk proyek boilerplate Anda.

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

Jalankan saja 'npm test' dan karma akan meluncurkan browser Anda dan akan mengawasi
perubahan.

Pada Tue, 12 Agustus 2014 di 10:35, Tyrone Avnit [email protected]
menulis:

Terima kasih @iamrandys https://github.com/iamrandys. Dikembangkan dengan cepat
reaksi-komponen-boilerplate
https://github.com/TYRONEMICHAEL/react-component-boilerplate yang menggunakan
Mocha dan Chai (Jasmine bisa diganti dengan mudah). Tes sangat
cepat dan Anda mendapatkan manfaat tambahan dari Livereload. Gunakan sesuai keinginan.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51931532.

Gunakan preprocessor.js berikut untuk menghindari file non-JSX yang mentransformasi JSX. Seperti itu, ini hanya memproses file .jsx yang berisi awalan /** @jsx . Jika Anda ingin mengubah file .js JSX, hapus saja bagian pertama dari kondisi if sebelum || (sehingga hanya kondisi src.slice ... tersisa).

// 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);
  }
};

Masih agak lambat, meskipun.

Cuplikan menarik @sqs. Perbaiki saya Jika saya salah, tetapi apakah itu masih tidak harus memeriksa setiap file dan memeriksa apakah perlu mengonversinya? Saya telah banyak sukses dengan berikut - react-component-boilerplate . Tes sebenarnya berjalan cukup cepat.

Sangat bagus. Ini mengurangi waktu dari 9,3 detik menjadi 4,7 detik. Ini untuk satu tes. Saya masih harus tetap dengan Karma yang jauh lebih cepat (100 tes membutuhkan waktu kurang dari satu detik). Plus, Karma akan melihat perubahan saat Anda bekerja dan akan menguji kode Anda di beberapa browser, tapi saya suka ejekan otomatis Jest. Membuat mata-mata secara manual menggunakan rewireify adalah pekerjaan ekstra, tetapi Anda memiliki kendali penuh.

Ya, saya mungkin salah paham dengan Anda, tetapi itulah yang saya maksud tentang menghapus centang untuk .jsx jika Anda memiliki file .js dengan jsx dan ingin mendeteksi berdasarkan header pragma.

dikirim dari iPhone saya

Pada 28 Agustus 2014, pukul 23:45, Tyrone Avnit [email protected] menulis:

Cuplikan menarik @sqs. Perbaiki saya Jika saya salah, tetapi apakah itu masih tidak harus memeriksa setiap file dan memeriksa apakah perlu mengonversinya? Saya telah banyak berhasil dengan yang berikut - react-component-boilerplate. Tes sebenarnya berjalan cukup cepat.

—
Balas email ini secara langsung atau lihat di GitHub.

Hai! Saya sedang mengerjakan --watch untuk lelucon dan umumnya mencoba membuatnya lebih cepat. Akan segera melaporkan kembali.

putaran pertama bagi saya membutuhkan waktu sekitar 5 detik (saya hanya memiliki satu tes, saya baru saja memulai). Setelah itu setiap putaran tambahan membutuhkan waktu sekitar 1,2-1,5 detik.

Sepertinya cukup banyak waktu yang dihabiskan untuk memuat cache tergesa-gesa (yang untuk proyek saya sudah menjadi file 4 mcg.

Saya menantikan pekerjaan --watch , tetapi saya juga bertanya-tanya apa yang terjadi yang membutuhkan waktu buka 1,2 detik untuk menjalankan tes? Saya tidak tahu apa-apa tentang apa yang dilakukan tergesa-gesa dan mengapa lelucon menggunakannya, jadi saya tidak tahu apa-apa.

Tergesa-gesa mendukung rasa format modul CommonJS adalah nama modul tingkat atas daripada relatif. Itu berarti kita perlu mengetahui modul (dan dependensi) sebelumnya sebelum menjalankan program jika tidak, akan sangat tidak efisien untuk melintasi sistem file untuk mencari modul pada setiap require . Namun kami menyadari bahwa kebanyakan orang menggunakan format modul relatif (a la node.js) dan kami ingin menghapus ketergantungan implisit pada Haste (kecuali opsi disediakan) dan ini akan membuatnya lebih cepat.

@amasad kedengarannya bagus. Saya sudah mencoba intern.js dan menjalankan tes unit reguler dari baris cmd hingga selesai dalam beberapa ms. Apakah Anda pikir lelucon bisa sampai secepat itu? Dan apakah Anda mempertimbangkan untuk mengekstrak bagian automocking sehingga dapat digunakan dalam kerangka kerja lain seperti melati atau moka?

Saya telah menemukan file yang membutuhkan (terutama 'react/addons' & modul yang sedang diuji) sekali di bawah panggilan balik yang dijelaskan, alih-alih berulang kali dalam panggilan balik beforeEach atau it membuat perbedaan besar.

Jelas, saya menggunakan skrip kopi dan bukan jsx, tetapi ini menghemat pekerjaan preprosesor dan lelucon yang berfungsi untuk mengejek panggilan require .

__tests__/login_fields.coffee (3.013s) (aduh!)

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
    ...

tapi, itu akan jauh lebih cepat dengan ...
__tests__/login_fields.coffee (0.604s) (tidak buruk)

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
  ...

Pengujian saya berlangsung selama 14 detik, bahkan setelah menggunakan semua pengoptimalan yang direkomendasikan sejauh ini. Bahkan dengan RAM 16GB dan SSD. Jest benar-benar tidak dapat digunakan dalam kondisi saat ini. Maaf, beralih ke Karma.

Saya telah menemukan kesuksesan besar dengan karma, mocha, chai, sinon, rewireify dan aliasify. Lebih dari 300 tes berjalan dalam 1/2 detik. Yang terbaik dari semuanya, React itu LUAR BIASA!!!!! Tim MENYUKAINYA dan telah mengembangkan beberapa hal yang sangat bagus dengannya. Ini sangat bersih dan terawat. Perbedaan besar dari apa pun yang pernah kami gunakan.

Baru saja mengalami ini sendiri. Tes berjalan _REALLY_ lambat. Masalah dengan tes lambat adalah pengembang menonaktifkannya atau hanya menjalankannya sebagian waktu. Tahu apa yang menyebabkan ini? Bagaimana saya bisa membantu?

Saya memiliki masalah persis ini - tes membutuhkan waktu sekitar 17 detik untuk dijalankan pada awalnya, dan kemudian 4 detik setelah caching. Ternyata direktori build dan modul eksternal saya tidak dikecualikan dengan benar. Menyetel opsi konfigurasi testPathDirs untuk menunjuk ke direktori sumber mengurangi waktu proses menjadi 0,5 detik.

Ini bekerja untuk saya menggunakan 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);
  }
};

Baru saja mulai menggunakan Jest - hanya menguji modul JavaScript biasa (tanpa JSX/Bereaksi) dan Jest sangat lambat. Saya menyukai ide tes inline dan ejekan bawaan, tetapi sangat lambat sehingga membuat saya merindukan Mocha. Saya tidak yakin apa pelakunya... tidak mencari pohon direktori yang menyebabkan kecepatan lambat. Jika saya menentukan file secara langsung, itu masih sangat lambat.

Adakah ide tentang setidaknya penyebab kelambatan? (Saya tidak menggunakan JSX / CoffeeScript; ejekan otomatis dimatikan)

Contoh asli tidak pernah berhasil untuk saya karena argumen pertama selalu benar.

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 terima kasih atas solusi yang bagus, persingkat tes 10s+ menjadi 2+. solusi ini membuat saya berpikir bahwa mungkin kita harus menggunakan ekstensi _.jsx/_.react.js untuk file reaksi kita, saya pikir itu mungkin membantu juga saat menggunakan reactify.

Sejujurnya melalui Grunt saya masih mendapatkan waktu +20-an, mengerti
Bereaksi bekerja dengan Karma dan total waktu sekitar +4/5 detik.

Semua di dalam VM sekalipun

Hanya untuk melaporkan kembali ini. Kami telah menguji reaksi dengan Karma/Mocha dan kami mendekati 700 tes dan dibutuhkan sekitar 4 detik untuk menjalankan semua tes. Kita memang harus mengolok-olok kudis, tapi itu sepadan. Bereaksi telah LUAR BIASA. Stabil tanpa cela dan menyegarkan. Pengubah permainan! Tim kami tidak dapat melakukan pencitraan menggunakan hal lain.

Saya tidak pernah membuat Jest menjadi cepat. Saya menggunakan moka. Jika Jest cepat, saya
akan menggunakannya sebagai gantinya.

Pada Kam, 5 Februari 2015 jam 12:17, Gil Birman [email protected]
menulis:

@iamrandys https://github.com/iamrandys maukah Anda menjelaskan di
lebih detail bagaimana Anda berhasil membuat lelucon begitu cepat?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/facebook/jest/issues/116#issuecomment -73097182.

Terima kasih @iamrandys saya telah menghapus "bagaimana Anda membuat lelucon menjadi cepat?" pertanyaan setelah menyadari saya telah salah membaca posting Anda (tetapi Anda menjawab pada saat yang sama) ... bagaimanapun, itu memalukan, saya kira lelucon masih harus dianggap belum siap untuk penggunaan produksi.

solusi/perubahan oleh @haihappen dan @darcyadams membantu saya menurunkan waktu pengujian dari 3,5 detik menjadi sekitar 1 detik untuk satu pengujian. Itu tidak memperhitungkan waktu startup yang terlihat, yang tampaknya juga sekitar 1 detik. Ini tampaknya terlalu lambat untuk menjadi efisien dalam pekerjaan sehari-hari, jadi saya rasa saya akan melihat kombo moka/karma. Saya suka filosofi Jest untuk mengejek semuanya secara default, tetapi manfaatnya tidak ada atm.

Saya memiliki masalah yang sama: Saya hanya mendapat 3 tes dalam proyek kecil dan mereka membutuhkan waktu 3 detik.

Apakah meningkatkan kinerja mendekati peta jalan proyek?

BTW: Saya menemukan cara (cukup hackish) untuk menjalankan kembali pengujian unit hanya untuk file yang telah berubah. Ini membuat mereka cukup cepat lagi, karena biasanya hanya ada satu tes yang harus dijalankan. Saya taruh di sini: https://Gist.github.com/mik01aj/fefb7718331e5454b9d1

Strange Jest tidak disebutkan pada konferensi React.js 2015.

testPathDirs tampaknya menjadi pelakunya. Tentukan seperti ini di package.json:

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

@adjavaherian hati-hati dengan itu jika Anda menggunakan ejekan otomatis: https://github.com/facebook/jest/issues/176

Bahkan, berharap ejekan otomatis pecah dengan cara yang halus dan membuat frustrasi jika testPathDirs Anda tidak mencakup dependensi Anda.

Kekhawatiran ini membuat saya berpikir kami mungkin melakukan sesuatu yang salah dengan pengaturan pengujian kami. Saya mungkin salah di sini, tetapi sejauh yang saya tahu, kita semua menggunakan hal-hal seperti: var component = React.createFactory(require("component/path")) bersama dengan modul lain yang diperlukan dalam tes beforeEach . Tentunya ini tidak harus diperlukan untuk semua tes. Maksud saya pabrik harus memproduksi komponen segar setiap saat. Jika saya memindahkan kebutuhan di luar kecepatan tes beforeEach blok meningkat 10x. Sayangnya, dalam kasus itu, beberapa tes anehnya gagal dan saya tidak tahu mengapa.

Tidak yakin apakah ini membantu. Pikiran?

akan lebih baik jika waktu preprocessing ditinggalkan dari waktu eksekusi tes yang dilaporkan. Agak tidak adil untuk melihat merah ketika sebagian besar pekerjaan itu berasal dari langkah transformasi.

Halo kawan-kawan,

Saya mempunyai masalah yang sama. Saya bahkan memiliki beberapa kasus uji yang membutuhkan waktu sekitar 1 menit untuk dijalankan :(

Saya tidak tahu harus mulai dari mana untuk membuat profil masalah kinerja, ada petunjuk?

MEMPERBARUI

Saya memperbaiki masalah ini yang hanya muncul di lingkungan VM saya (lih: http://stackoverflow.com/a/13703132). Sekarang tes masih lebih lambat dari yang saya harapkan tetapi jauh lebih cepat daripada sebelum perbaikan gelandangan ( 60 detik -> 6 detik untuk setelan tes saya)

Jika kecepatan masih menjadi masalah, saya sarankan pindah ke Mocha. Kami telah meraih banyak keberhasilan dengan fork ini, yang menjelaskan cara menyiapkan pengujian untuk penerapan React yang sederhana hingga yang kompleks. https://github.com/adjavaherian/mocha-react Kami secara teratur menjalankan lebih dari 100 tes dalam waktu sekitar 3 detik.

Saya setuju Mocha adalah cara untuk pergi. Hingga hampir 900 tes dan dibutuhkan sekitar 4 detik.

Pada 23 April 2015, pukul 16.53, Amir Djavaherian [email protected] menulis:

Jika kecepatan masih menjadi masalah, saya sarankan pindah ke Mocha. Kami telah meraih banyak keberhasilan dengan fork ini, yang menjelaskan cara menyiapkan pengujian untuk penerapan React yang sederhana hingga yang kompleks. https://github.com/adjavaherian/mocha-react Kami secara teratur menjalankan lebih dari 100 tes dalam waktu sekitar 3 detik.

—
Balas email ini secara langsung atau lihat di GitHub.

Pengalaman yang sama, saya hanya mengatur Jest hanya dengan satu tes (menggunakan JSX) dan membutuhkan waktu sekitar 3 detik, ini banyak.

@iamrandys apakah Anda keberatan menunjukkan contoh pengaturan Anda? Sepertinya kombinasi yang sempurna.

@amasad Apakah ada opsi dengan Jest untuk membangun cache untuk file yang dikompilasi mirip dengan apa yang diizinkan oleh babel-loader dalam opsi cacheDirectory? - https://github.com/babel/babel-loader#options

Apa yang membuat lelucon lambat bagi saya bukanlah kompilasi melainkan permulaan proses kumpulan pekerja. Semua tes saya lulus dalam waktu kurang dari 0,05 detik kecuali yang pertama, yang memakan waktu sekitar 4 detik.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

@songawee Tidak tetapi ingin mengirim PR untuk memilikinya sebagai opsi? Saya tidak berpikir kita harus mengaktifkannya secara default karena terkadang tidak mungkin untuk mengetahui kapan harus memecahkan cache. Misalnya, jika Anda mengubah opsi kompiler, cache harus disetel ulang. Pilihan lain adalah memiliki opsi reset-cache selain caching.

@doodzik apakah Anda yakin itu kumpulan pekerja dan bukan node-haste menyatakan dan membaca modul?

@amasad Apa yang saya lakukan adalah mengukur waktu yang dibutuhkan setiap langkah dalam menjalankan jest untuk penyelesaian.
Dan node-worker-pool adalah contoh terakhir di mana pengujiannya lambat.
Bisa jadi temuan saya hanya gejala dan bukan akar masalahnya.
Tapi saya tidak punya waktu untuk memberikan analisis yang tepat.

Tes saya saat ini terlihat seperti ini:

Tes reaksi saya lambat (yang ada di folder contoh). Apa yang saya bicarakan adalah tes non-reaksi.

+1

Sama disini. Tes sangat sangat lambat :kecewa:

Saya pikir hanya saya yang menghadapi masalah ini. Ini adalah pertama kalinya saya menggunakan Jest dan saya juga tidak mendapatkan hasil tes yang cepat. Ingin tahu bagaimana Facebook melakukan tes menggunakan Jest?

Pertanyaan saya tentang peningkatan Jest ke React guys di sesi Q&A konferensi React Europe - https://youtu.be/CRJZBZ_-6hQ?t=363

Beralih ke Moka + Sinon. Tidak pernah lebih bahagia.

Pada 31 Agustus 2015 pukul 17:45, Alan Rubin [email protected] menulis:

Pertanyaan saya tentang Jest to the React guys di konferensi React Europe Q&A
sesi - https://youtu.be/CRJZBZ_-6hQ?t=363

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/facebook/jest/issues/116#issuecomment -136394910.

Saya memiliki masalah yang sama. Tes lelucon hanya membutuhkan banyak waktu dan waktu eksekusi sebenarnya bervariasi. Apakah akan menjalankannya secara paralel atau hanya dalam satu proses (--runInBand) tidak masalah. Tampaknya tidak menjadi pertikaian sumber daya antara proses pekerja.

Saya membuat beberapa dump cpu dengan profiler v8 (https://github.com/node-inspector/v8-profiler) dan menemukan bahwa sebagian besar waktu tampaknya dihabiskan untuk mengejek modul. Yaitu 25% dari waktu eksekusi pengujian unit saya dihabiskan di jest-cli/src/lib/utils.js#runContentWithLocalBindings.

ada update performa? baru saja mengambil lelucon dengan es6 dan babel-jest, tetapi menjalankan 2 tes sederhana dalam> 10 detik :-(
mencoba banyak ide dari utas ini untuk mempercepat, tetapi tidak ada yang berhasil ...

Kami akan segera fokus pada ini. Kami sedikit dibanjiri dengan pekerjaan bercanda sekarang, tetapi kami berkomitmen untuk membuatnya lebih mengagumkan.

Apakah ada tugas yang dapat dibantu oleh komunitas?

+1

Bantuan terbesar saat ini sebenarnya adalah meningkatkan dokumentasi, situs web, dan mengatasi masalah serta membantu orang-orang di sumber terbuka.

Satu hal yang telah kami lakukan untuk mempercepat pengujian JEST kami di jalur pembuatan adalah mengganti mesin inti tunggal kami dengan mesin multi inti. Secara default, lelucon memunculkan pekerja sebanyak utas perangkat keras yang tersedia. Jika ini tidak tersedia untuk Anda, Anda dapat bermain secara manual dengan '-w' (maxWorkers). Anda dapat memperoleh percepatan juga pada satu inti.

Pada akhirnya kami menemukan bahwa modul mocking sangat mahal (lihat komentar saya di atas) dan menyebabkan sebagian besar waktu eksekusi.

Bercanda dengan es6 bagi saya sama sekali tidak dapat digunakan. dibutuhkan 10+ detik hanya untuk memulai, dan kemudian dibutuhkan 2 detik untuk menjalankan tes tunggal yang saya miliki saat ini. Saya mengharapkan lebih banyak, beralih kembali ke karma :(

Kami sedang berupaya mengganti node-haste dengan resolver modul baru, yang akan memperbaiki masalah ini.

Halo semua. Apakah ada berita tentang masalah ini?

Hai, apakah Jest cocok untuk pengujian non Bereaksi? Ingin memiliki standar umum untuk aplikasi reaksi dan non-reaksi di tim kami.

Jest adalah uji coba universal dan Anda sama sekali tidak diharuskan menggunakan React. :) Lihat saja salah satu contohnya!

Hi semua, beberapa info menarik nyata di sini. Saya juga mengalami masalah dengan tes yang berjalan lambat juga. Saat ini saya memiliki 13 tes yang membutuhkan waktu ~ 15 detik untuk dijalankan.

Saya menemukan menambahkan "testPathDirs": ["<rootDir>/path/to/tests/"] ke file package.json kami membantu meningkatkan waktu startup secara signifikan.

@cpojer Apakah Anda mendapat pembaruan untuk kami mengenai penyelesai modul yang baru dan lebih baik? Saya sangat berharap ini akan menjadi kunci untuk menjalankan tes lebih cepat

Pekerjaan ini terjadi di #599.

Terima kasih @cpojer 😀
Saya berharap untuk melihat Haste2 yang sudah selesai

Tes yang sama menggunakan mocha berjalan dalam 44 ms untuk saya di mana lelucon membutuhkan waktu 6 detik penuh.

Butuh waktu sekitar 15 menit untuk mengganti 6 file pengujian awal saya menggunakan jest untuk menggunakan Mocha , jsdom dan sinon .

Kabar baik semuanya, saya menggabungkan #599 hari ini dan akhirnya akan menghilangkan startup yang lambat.

Oke, ini akhirnya harus diperbaiki di Jest 0.9. Maaf ini butuh waktu lama tapi ada beberapa badut di Jest :)

Lihat https://github.com/facebook/react/pull/6052 tentang bagaimana tes React sendiri dipercepat. Jika Anda ingin mencoba peningkatan ini, lihat komentar di #599. Saat ini ditandai sebagai jest-cli@next sampai untuk melihat apakah ada bug yang mungkin ditemui orang-orang di open source. Saya akan menutup masalah ini sebagai diselesaikan.

npm install jest-cli@next jika Anda ingin menjalankan versi baru ini (bukan jest@next @cpojer)

oh ya, saya selalu membuat kesalahan ini :) Saya mengedit komentar asli saya.

@cpojer setelah memutakhirkan menggunakan npm install jest-cli@next Saya mengalami masalah dalam menentukan dontMock . Maksud saya, sebelum pembaruan (menggunakan [email protected]) baris ini berfungsi dengan baik:

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

kemudian setelah pembaruan ke 0.9.0, panggilan yang sama menghasilkan modul yang diejek

@steinbachr yang mungkin harus masuk ke masalah terpisah. Akan lebih bagus jika Anda bisa memberikan repro, belum pernah melihat masalah ini muncul di FB!

terima kasih @cpojer , masalah dibuat di sini