Jest: Тесты на медленную реакцию

Привет, Тайрон. Была эта проблема с 20+ секундами для одного файла :)
Дело в том, что я настроил просто запускать jest в корневом каталоге. И есть МНОГО подкаталогов, которые Jest проверял на предмет тестов. Указание пути для тестов сократило это время более чем в 10 раз. И еще у меня есть препроцессор для кофе. В package.json
"scripts": {
....
"тест": "путь для шутки / к / модулям / к / тесту"
}

Кстати, вы предварительно обрабатываете кофе или как? :)

Спасибо, что ответили мне @gothy. Я использую обычный JS с JSX. Я просто запускаю свои тесты через препроцессор JSX, как в примере (https://github.com/facebook/jest/tree/master/examples/react). Пример также занимает около 2,5–3 секунд. Пример jQuery занимает меньше секунды. Неужели препроцессор JSX отнимает столько времени при обработке ваших файлов JSX?

Реагировать тест

jQuery Test

Ах, я не использовал его для JSX. Ничего не могу сказать по этому процессору. Может быть, это действительно медленно. Я обнаружил свою проблему с каталогами в реальном проекте со множеством старых вещей :)

У меня возникла аналогичная проблема с препроцессором Coffeescript. Я думаю, проблема здесь в том, что препроцессор тоже пытается обработать ваши зависимости. Если вам понадобится много вещей, это замедлится.

Я точно также испытываю медленные тесты с шуткой :(

Я испытываю то же самое. Я не думаю, что это связано с предварительной обработкой (обработка JSX в этом небольшом файле выполняется быстро). Я закомментировал весь код в примере теста, кроме одного из следующих операторов require, и тест по-прежнему занимает 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 с помощью reactify, но удаляет предупреждающее сообщение для медленных тестов. Таким образом, время выполнения по-прежнему занимает чуть менее 2 секунд, но фактический тест составляет около 32 мсек. Все еще решаете, стоит ли использовать JSX.

О, ты прав. Я протестировал пример шутливой реакции без использования JSX, и он снизился с почти 4 секунд до 0,75 секунды. Это заставляет меня задуматься, стоит ли использовать JSX. В большом проекте он довольно быстро замедлится, если у меня не будет много разных пакетов. Интересно, работает ли препроцессор для всех 490 требований, а не только для этого одного файла. Невозможно, чтобы для этого простого компонента потребовалось 3 секунды.

В любом случае, мне действительно нужно, чтобы тесты были быстрыми для моего рабочего процесса. Мне все еще нужно выяснить, как запустить хотя бы один пакет. В jasmine я мог бы использовать «ddescribe» или «iit» вместо «describe» и «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, watchify и реагировать, чтобы обрабатывать только измененные файлы 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 Тайрон Авнит [email protected] написал:

@iamrandys https://github.com/iamrandys Я на 100% согласен с вами. Шутка и
React - это круто, но компиляция 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.

Собственно говоря, использование gulp и watchify удивительно быстро реагирует. Бросить в
gulp-livereload, чтобы обновлять ваш браузер после каждого изменения, и у вас есть
потрясающая среда разработки. Вы вносите любые изменения, сохраняете, и вы почти
мгновенно увидеть изменения во всех открытых браузерах и на всех устройствах. Сейчас я
просто нужно то же самое для моего TDD.

Это примерно так, но используйте reactify вместо hbsfy.
https://gist.github.com/benhowdle89/9533185

В понедельник, 11 августа 2014 г., в 2:35, Тайрон Авнит [email protected]
написал:

@iamrandys https://github.com/iamrandys Я на 100% согласен с вами. Шутка и
React - это круто, но компиляция 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. Разработан шаблон компонента с быстрой

В любом случае, мне действительно нужно, чтобы тесты были быстрыми для моего рабочего процесса. Мне все еще нужно выяснить, как запустить хотя бы один пакет. В jasmine я мог бы использовать «ddescribe» или «iit» вместо «describe» и «it» для запуска одного теста или набора. Шутка ТАК хороша, мне просто нужен быстрый рабочий процесс.

Вы определенно можете написать it.only и я верю, что вы тоже можете написать describe.only .

Карма делает именно то, что вы хотите, и все, что вам нужно сделать, это добавить
karma.conf в свой проект. Я не понимал, что карма поддерживает повторную активацию
и просматривайте. Теперь вы можете тестировать во всех своих браузерах одновременно.
Я создал PR для вашего шаблонного проекта.

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

Просто запустите npm test, и karma запустит ваши браузеры и будет следить за
изменения.

Во вторник, 12 августа 2014 г., в 10:35, Тайрон Авнит [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-преобразовать файлы .js , просто удалите первую часть условия 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. Создание шпионов вручную с помощью rewireify - это дополнительная работа, но у вас есть полный контроль.

Да, возможно, я вас неправильно понимаю, но это то, что я имел в виду, говоря об удалении проверки для .jsx, если у вас есть файлы .js с jsx и вы хотите обнаружить их на основе заголовка прагмы.

отправлено из моего Айфона

28 августа 2014 г. в 23:45 Тайрон Авнит [email protected] написал:

Интересный сниппет @sqs. Поправьте меня Если я ошибаюсь, но разве ему все равно не придется просматривать каждый файл и проверять, нужно ли его преобразовать? У меня был большой успех со следующим - реагировать-компонент-шаблон. На самом деле тесты проходят довольно быстро.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Привет! Я работаю над --watch для шутки и вообще пытаюсь сделать это быстрее. Скоро сообщу.

первый прогон для меня занимает около 5 секунд (у меня только один тест, я только начинаю). После этого каждый дополнительный запуск занимает около 1,2–1,5 с.

Похоже, что приличное количество этого времени тратится на загрузку кеша ускорения (который для моего проекта уже является файлом размером 4 мегабайта.

Я с нетерпением жду работы --watch , но мне также интересно, что происходит, для выполнения теста требуется 1,2 секунды времени загрузки? Я ничего не знаю о том, что делает спешка и почему ее используют шутки, так что я довольно невежественен.

Haste поддерживает разновидность формата модуля CommonJS, где имена модулей являются верхними, а не относительными. Это означает, что нам нужно знать модули (и зависимости) заранее, прежде чем запускать программу, иначе было бы невероятно неэффективно обходить файловую систему в поисках модуля на каждом require . Однако мы понимаем, что большинство людей используют относительный формат модуля (а-ля node.js), и мы хотим удалить неявную зависимость от Haste (если не предоставлена ​​опция), и это должно ускорить работу.

@amasad, это здорово. Я пробовал intern.js, и он запускает обычный модульный тест из строки cmd до завершения за несколько мс. Как вы думаете, шутка может дойти так быстро? А вы не думали об извлечении части автозапуска, чтобы ее можно было использовать в других фреймворках, таких как jasmine или mocha?

Я обнаружил, что требующиеся файлы (особенно 'react / addons' и тестируемый модуль) один раз при обратном вызове описать, а не повторно в 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 полностью непригоден для использования. Извините, переключаюсь на Карму.

Я добился большого успеха с карма, мокко, чай, синон, rewireify и aliasify. Более 300 тестов выполняются за полсекунды. Лучше всего React УДИВИТЕЛЬНЫЙ !!!!! Команде это нравится, и они разработали с его помощью несколько действительно хороших вещей. Он такой чистый и удобный. Огромное отличие от всего, что мы когда-либо использовали.

Просто столкнулся с этим сам. Тесты выполняются ДЕЙСТВИТЕЛЬНО медленно. Проблема с медленными тестами заключается в том, что разработчики отключают их или запускают только часть времени. Есть идеи, что вызывает это? Чем могу помочь?

У меня была именно эта проблема - сначала тесты занимали около 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 очень медленный. Мне нравится идея встроенных тестов и встроенных насмешек, но она настолько медленная, что мне не хватает Mocha. Я не уверен, в чем виноват ... это не поиск в дереве каталогов, который вызывает медленную скорость. Если я укажу файл напрямую, он все равно будет очень медленным.

Есть идеи хотя бы о причине медлительности? (Я не использую 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 для наших файлов реакции, я думаю, что это тоже может помочь при использовании reactify.

Если честно, проходя через Grunt, я все еще получал время +20, получил
Реагируйте при работе с Karma, и общее время составляет около +4/5 секунд.

Хотя все внутри виртуальной машины

Просто чтобы доложить об этом. Мы тестировали реакцию с помощью Karma / Mocha, и мы приближаемся к 700 тестам, и для запуска всех тестов требуется около 4 секунд. Придется чинить моки, но оно того стоит. React был УДИВИТЕЛЬНЫМ. Безупречный и освежающий. Измените правила игры! Наша команда не смогла получить изображения с помощью чего-либо еще.

Я никогда не заставлял Jest работать быстро. Я использую мокко. Если бы Jest был быстрым, я
использовал бы его вместо этого.

В четверг, 5 февраля 2015 г., в 12:17, Гил Бирман [email protected]
написал:

@iamrandys https://github.com/iamrandys не могли бы вы объяснить в
подробнее, как тебе удалось так быстро пошутить?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/facebook/jest/issues/116#issuecomment -73097182.

Спасибо @iamrandys. Я удалил мое "как ты получил шутку, чтобы быть быстрым?" вопрос после того, как я понял, что неправильно прочитал ваш пост (но вы ответили в то же время) ... в любом случае, это позор, я думаю, что шутку все же следует считать не очень готовой для использования в производстве.

обходные пути / изменения @haihappen и @darcyadams помогли мне

У меня такая же проблема: у меня всего 3 теста в небольшом проекте, и они занимают 3 секунды.

Находится ли улучшение производительности в планах проекта?

Кстати: я нашел (довольно хакерский) способ повторно запустить модульные тесты только для файлов, которые были изменены. Это делает их снова довольно быстрыми, поскольку обычно требуется запустить только один тест. Я положил сюда: https://gist.github.com/mik01aj/fefb7718331e5454b9d1

Strange Jest не упоминался на конференции 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")) вместе с другими необходимыми модулями в рамках теста beforeEach block test скорость увеличивается в 10 раз. К сожалению, в этом случае некоторые тесты неожиданно терпят неудачу, и я не знаю почему.

Не уверен, что это поможет. Мысли?

было бы неплохо, если бы время предварительной обработки не входило в заявленное время выполнения теста. Это несправедливо видеть красный цвет, когда большая часть работы приходится на этап трансформации.

Привет, народ,

У меня такая же проблема. У меня даже есть несколько тестовых примеров, выполнение которых занимает около 1 минуты :(

Я не знаю, с чего начать профилирование проблемы с производительностью, есть намек?

ОБНОВИТЬ

Я исправил эту проблему, которая появлялась только в моей среде виртуальной машины (см. Http://stackoverflow.com/a/13703132). Теперь тесты по-прежнему медленнее, чем я ожидал, но намного быстрее, чем до исправления бродяг (60 секунд -> 6 секунд для моего тестового костюма)

Если скорость все еще остается проблемой, я предлагаю перейти в Mocha. Мы добились большого успеха с этой вилкой, которая объясняет, как настроить тесты для простых и сложных развертываний React. https://github.com/adjavaherian/mocha-react Мы регулярно запускаем более 100 тестов примерно за 3 секунды.

Я согласен, что Mocha - это то, что вам нужно. До почти 900 тестов и это занимает около 4 секунд.

23 апреля 2015 года в 16:53 Амир Джавахериан [email protected] написал:

Если скорость все еще остается проблемой, я предлагаю перейти в Mocha. Мы добились большого успеха с этой вилкой, которая объясняет, как настроить тесты для простых и сложных развертываний React. https://github.com/adjavaherian/mocha-react Мы регулярно запускаем более 100 тестов примерно за 3 секунды.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Тот же опыт, я только что установил Jest только с одним тестом (с использованием JSX), и это занимает около 3 секунд, это много.

@iamrandys не могли бы вы показать пример своей установки? Похоже на идеальное комбо.

@amasad Есть ли в Jest возможность создать кеш для скомпилированных файлов, аналогичный тому, который позволяет babel-loader в параметре cacheDirectory? - https://github.com/babel/babel-loader#options

Для меня jest замедляет не компиляция, а запуск процессов рабочего пула. Все мои тесты проходят менее чем за 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 Q&A - https://youtu.be/CRJZBZ_-6hQ?t=363

Перешел на Мокко + Синон. Никогда не был так счастлив.

31 августа 2015 года в 17:45 Алан Рубин [email protected] написал:

Мой вопрос о Jest ребятам из React на конференции React Europe Q&A
сессия - https://youtu.be/CRJZBZ_-6hQ?t=363

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/facebook/jest/issues/116#issuecomment -136394910.

У меня точно такая же проблема. Просто Jest-тесты занимают много времени, и время выполнения действительно варьируется. Неважно, запускать ли их параллельно или в одном процессе (--runInBand). Похоже, это не конфликт ресурсов между рабочими процессами.

Я создал несколько дампов процессора с помощью профилировщика v8 (https://github.com/node-inspector/v8-profiler) и обнаружил, что большая часть времени уходит на имитацию модулей. Т.е. 25% времени выполнения моего модульного теста уходит в jest-cli / src / lib / utils.js # runContentWithLocalBindings.

какие-нибудь обновления производительности? просто взял jest с помощью es6 и babel-jest, но запустил 2 простых теста за> 10 секунд :-(
перепробовал много идей из этой ветки для ускорения, но ничего не получилось ...

Вскоре мы сосредоточимся на этом. Сейчас мы немного перегружены работой над шуткой, но мы стремимся сделать ее еще круче.

Есть ли задачи, с которыми может помочь сообщество?

+1

Самая большая помощь прямо сейчас - это улучшение документации, веб-сайта, решение проблем и помощь людям с открытым исходным кодом.

Одна вещь, которую мы сделали, чтобы ускорить наши тесты JEST в конвейере сборки, - это заменить нашу одноядерную машину на многоядерную. По умолчанию jest порождает столько рабочих, сколько доступно аппаратных потоков. Если вам это недоступно, вы можете вручную поиграть с '-w' (maxWorkers). Вы можете получить ускорение также на одном ядре.

В конечном итоге мы обнаружили, что имитирующие модули очень дороги (см. Мой комментарий выше) и вызывают большую часть времени выполнения.

Шутка с es6 для меня совершенно непригодна. для запуска требуется 10+ секунд, а затем требуется 2 секунды для запуска единственного теста, который у меня есть на данный момент. Я ожидал намного большего, переключившись обратно на карму :(

В настоящее время мы работаем над заменой node-haste новым преобразователем модулей, который должен решить эту проблему.

Всем привет. Есть какие-нибудь новости по этому поводу?

Привет, подходит ли Jest для тестирования без React? Хотелось бы иметь в нашей команде общий стандарт как для реагирующих, так и для нереагирующих приложений.

Jest - это универсальный инструмент для запуска тестов, и от вас никоим образом не требуется использовать React. :) Взгляните на один из примеров!

Привет всем, здесь есть действительно интересная информация. У меня также возникают проблемы с медленным запуском тестов. В настоящее время у меня есть 13 тестов, на выполнение которых требуется ~ 15 секунд.

Я обнаружил, что добавление "testPathDirs": ["<rootDir>/path/to/tests/"] в наш файл packages.json помогло значительно сократить время запуска.

@cpojer У вас есть

Эта работа происходит в № 599.

Спасибо @cpojer 😀
С нетерпением жду законченного Haste2

Те же тесты с использованием мокко выполнялись для меня за 44 мс, а шутка длилась полных 6 секунд.

Мне потребовалось около 15 минут, чтобы переключить мои начальные 6 тестовых файлов с использованием 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, который, вероятно, должен быть выделен в отдельный выпуск. Было бы здорово, если бы вы могли предоставить репродукцию, вы не видели, чтобы эта проблема поднималась в FB!

спасибо @cpojer , проблема создана здесь