Mocha: Устарело - смотреть

Созданный на 5 июл. 2015  ·  37Комментарии  ·  Источник: mochajs/mocha

@boneskull прокомментировал 30 янв.

ИМО "часы" надо убить. Есть и другие инструменты, которые делают это намного лучше.

@dasilvacontin прокомментировал 31 янв.

+1, чтобы убить часы. Я не вижу смысла копировать функциональность наблюдателя внутри проекта, когда с этим справится любой инструмент-наблюдатель.

Создадим для этого отдельную задачу, чтобы мы могли закрыть несвязанный # 871

chore future

Самый полезный комментарий

Все предлагаемые здесь альтернативы, похоже, игнорируют главный момент: --watch Mocha настолько полезен, потому что процесс Node, запускающий тесты, остается в живых.

Если у вас очень маленький проект с очень небольшим количеством зависимостей и вы не выполняете транспиляцию, вам даже не нужен инструмент Node для просмотра файлов и запуска команды оболочки. Это уже придумано и хорошо работает: http://entrproject.org.

Тем из нас, у кого есть несколько более крупные проекты, использующие транспиляцию Babel, нужно будет найти альтернативу. Одиноки. То есть тот, который поддерживает работу Mocha и не должен повторно запускать процесс Node со всем, что влечет за собой.

Все 37 Комментарий

Да, пожалуйста

Согласованный. Мне бы очень хотелось, чтобы Mocha v3 был разбит на более мелкие модули с минимальным ядром.

Тогда было бы неплохо увидеть несколько предложений по альтернативе; все: +1: очевидно, знают о лучшей замене, но лично я не знаю. (Я подозреваю, что то же самое верно и для многих пользователей .: P)

Было бы неплохо увидеть несколько предложений по альтернативе

https://github.com/gruntjs/grunt-contrib-watch
https://github.com/floatdrop/gulp-watch

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

Не все используют задачи grunt / gulp для такого рода вещей, некоторые люди любят использовать для этого сценарии npm.

Это также очень полезно с флагом compilers . Да, вы можете использовать что-то вроде:
forever start -c "mocha /path" /path . Но это кажется намного более сложным, чем должно быть.

"делай одно и делай это хорошо"

Мокко хорошо проводит тесты. Он плохо смотрит файлы. Есть решения получше. Я понимаю, что некоторым людям это удобно, но это выходит за рамки возможностей.

Какая альтернатива?

читать выше

Не могли бы вы также прочитать мой комментарий ?

Я сделал. Но независимо от того, используете ли вы средство выполнения задач, forever , fswatch или что-то еще, по вашему выбору.

Я не уверен, что forever start -c "mocha /path" /path будет работать, не запустился для меня, не уверен, что даже если это должно быть.

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

взгляд , вероятно, будет вашим лучшим выбором

если вам не нужно что-то, основанное на узлах, gaze - это оболочка вокруг отличного fswatch

многие IDE и текстовые редакторы также имеют встроенную функцию

fswatch не может быть добавлен как зависимость узла, gaze не имеет API интерфейса командной строки. В том числе предварительное условие для проектов, использующих некоторую IDE, кажется ...

Хорошо, другими словами, мне либо нужно переключить свои проекты на какой-нибудь диспетчер задач, либо я все еще могу использовать mocha но только через программный API с некоторым наблюдателем.

На мой взгляд, это плохой ход.

re: fswatch "если вам не нужно что-то на основе узлов" ... это не пакет узлов. apt-get install fswatch или brew install fswatch или что там такое.

Я не уверен, зачем мне это делать, но вот интерфейс командной строки для взора .

re: fswatch "если вам не нужно что-то на основе узлов" ... это не пакет узлов. apt-get install fswatch или brew install fswatch или что-то еще.

Да, именно поэтому я сказал, что «fswatch не может быть добавлен как зависимость узла», это все равно что просить людей установить пакет debian для запуска mocha .

вот CLI для взгляда.

Это то же самое, что и forever start -c "mocha /path" /path , см. Выше, как говорится :-), это менее круто, и вы не можете поместить его в mocha.opts , если используете compiler флаг, дела идут еще хуже. Но ладно, подойдет.

Я не уверен, зачем мне это делать за тебя

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

Объяснение - необходимость, альтернативный способ, обычная вежливость, знак взаимного уважения, а не услуга.

Другими словами, вам «не нужно» ничего делать, и мне очень жаль, что мне «нужно» это написать.

Да, именно поэтому я сказал, что «fswatch не может быть добавлен как зависимость узла», это все равно что просить людей установить пакет debian для запуска mocha.

да. Хотя gaze - это оболочка вокруг fswatch . Когда вы его устанавливаете, он компилирует за вас fswatch . Существует очень много оболочек NodeJS для проектов, не относящихся к NodeJS. А некоторые просто ожидают, что там будет исполняемый файл. Например, как бы вы запустили npm без установленного git ? Так что, на мой взгляд, не грандиозное дело, а жизнеспособная альтернатива.

Объяснение - необходимость, альтернативный способ, обычная вежливость, знак взаимного уважения, а не услуга.

_Когда прекращается поддержка_, ответственно будет объяснить жизнеспособную альтернативу - и мы это сделаем!

Мой комментарий был разочарован; очевидно, что есть жизнеспособные альтернативы, и я знаю, что вы это знаете. Я чувствовал, что должен "погуглить" за вас. Это не должно было быть неуважением, и я прошу прощения, если это натолкнулось на это.

Я использую grunt-contrib-watch если мне нужен наблюдатель во всех моих проектах. В большинстве случаев я этого не делаю, потому что моя IDE делает это за меня. Это решение работает для меня.

Когда придет время, мы предоставим хорошо задокументированные альтернативы, так что спасибо за напоминание. Фактически, при использовании --watch может оказаться целесообразным добавить уведомление «ожидает прекращения поддержки».

Нам не нужно было бы «гуглить», за исключением того, что я просил вас сделать именно это. Думаю, @markelog просто разъяснял мою просьбу.

Что касается того, почему я спросил: мне не интересно, какие решения _are_ (я не новичок. Я действительно знаю, как использовать поисковую систему.); Я спрашиваю, каким будет ответ _Mocha на этот вопрос_, когда он устарел. Мне жаль, что я не сказал этого лучше.

Если gaze-cli будет предложенным средством для сбитых с толку пользователей (прочтите еще раз, потому что, по-видимому, мне нужно указать это: не я), я все же думаю, что mocha --watch widget существенно СУХОЕ и более доступное, чем gaze "mocha widget" widget , или так далее и тому подобное.

Лично я не думаю, что это проблема с блокировкой из-за отказа от этого. Я полностью за это. ¯_ (ツ) _ / ¯

@ELLIOTTCABLE @markelog Может быть, это .

Поскольку gaze теперь явно отказано от ПО, а большинство крупных проектов (Gulp, browserify, Karma) перешли на Chokidar , могу ли я предложить chokidar-cli ?

В дополнение к более широкой поддержке, он решает одну проблему, о которой я говорил выше, предоставляя замену {path} , позволяя нам СУШИТЬ команду Mocha:

chokidar 'tests/*.js' -c 'mocha "{path}"'

Для этого я использую https://github.com/testem/testem .

@ELLIOTTCABLE Да, чокидар - это то, что нужно

При использовании mocha --watch первый тестовый запуск занимает ~ 20 секунд, я полагаю, пока все компилируется и загружается. После этого изменение файла запускает повторный тестовый запуск менее чем за 1 секунду, и это прекрасно.

Тем не менее, mocha --watch заставляет мои процессоры резко повышаться. Это делает то же самое для кого-то еще? Обидно оставлять это на ночь.

Chokidar этого не делает, но ему также требуется полное 20-секундное время компиляции при каждом изменении файла :(

Есть ли лучшее из обоих миров решение?

@sosaucily Предположительно, написание файла JavaScript, который отслеживает файлы с помощью Chokidar API и программно вызывает Mocha, вместо использования вызова CLI, будет быстрее.

Было бы здорово, если бы мы могли диагностировать скачки производительности процессора. Любая помощь будет оценена по достоинству!

Во всяком случае, чокидар> взгляд

-1 за это. Мне нравится каждый элемент --watch, насколько легко его настроить и как он вписывается в мой раздел package.json / scripts. Пожалуйста, не убивайте его !!!

@padcom Mocha не занимается просмотром файлов. Мы часто сталкиваемся с множеством проблем, связанных с функциональностью часов, потому что они не работают так, как люди думают, или имеют ошибки в крайних случаях, или не работают на разных платформах. Для этого его следует удалить из «ядра». Функциональность полезна, но с ней лучше справиться сторонним инструментом.

Тем не менее, есть определенные варианты использования, которые, скорее всего, не будут работать «из коробки» со сторонним инструментом. Нужен отдельный модуль, который чокидара . mowatch был / был экспериментальным инструментом для обеспечения этого за пределами ядра Mocha. Он не использует чокидар, но должен.

Более того, я считаю, что chokidar раздражает (генерирует предупреждения npm при каждой установке npm из-за того, что npm не поддерживает несколько платформ). Поэтому я всегда предпочел бы, чтобы наблюдатель был отдельным инструментом для конкретной платформы, а не интегрировался в средство выполнения тестов.

Все предлагаемые здесь альтернативы, похоже, игнорируют главный момент: --watch Mocha настолько полезен, потому что процесс Node, запускающий тесты, остается в живых.

Если у вас очень маленький проект с очень небольшим количеством зависимостей и вы не выполняете транспиляцию, вам даже не нужен инструмент Node для просмотра файлов и запуска команды оболочки. Это уже придумано и хорошо работает: http://entrproject.org.

Тем из нас, у кого есть несколько более крупные проекты, использующие транспиляцию Babel, нужно будет найти альтернативу. Одиноки. То есть тот, который поддерживает работу Mocha и не должен повторно запускать процесс Node со всем, что влечет за собой.

+1 о сохранении --watch по ранее упомянутым причинам. Предпочтительно такие параметры, как compilers и watch должны стать частью самой библиотеки Mocha, поскольку теперь они вносят ненужную сложность в инструменты-оболочки, которые хотят поддерживать эти же функции. Смотрите эту ветку .

У меня немного другой взгляд на это: если разница между интерфейсом командной строки Mocha и его JS API не позволяет использовать инструменты-оболочки, мы должны уменьшить эти различия в целом, чтобы инструменты-оболочки работали правильно, _включая специальную оболочку-наблюдатель_ вместо подсчета наблюдая как среди вещей, которые нужно запихнуть в библиотеку.

У меня аналогичный подход к проблеме времени загрузки: JS API Mocha в любом случае нуждается в лучшей поддержке для запуска более одного раза, среди других проблем, и если мы получим такие улучшения, тогда специальный инструмент наблюдения должен иметь возможность использовать JS API, чтобы избежать полная перезарядка.

В конечном счете, я бы сказал, что --watch - это повязка на то, что _другие проблемы_ с программным использованием Mocha мешают использовать с ним надлежащие инструменты-наблюдатели, и эти проблемы необходимо исправить раньше. или позже независимо.

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

Я согласен с @padcom (этот аргумент очень важен)

-1 за это. Мне нравится каждый элемент --watch, насколько легко его настроить и как он вписывается в мой раздел package.json / scripts. Пожалуйста, не убивайте его !!!

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

Я повторяюсь, но учтите это.

watch-run -i -p 'src/**/*' npm test:mocha

Он работает отлично, однако по мере роста базы кода требуется все больше и больше времени. Причина? С помощью транспайлера.

 "test:mocha": "mocha ./internals/test.setup.js ./src/**/*.spec.js* --require babel-core/register", 

Каждый раз при изменении файла mocha требует babel-register. Это означает, что вы тратите время на транспилирование всего, в то время как повторный запуск тестов мокко с mocha --watch занимает немного начального времени, но после запуска он выполняется очень быстро.

Интересная мелочь (или, возможно, пример расстановки приоритетов и вещей, которые идут медленно): исследуя другую проблему, я обнаружил, что --watch не является предпочтительным с 2013 года: https://github.com/ mochajs / mocha / issues / 909 # issuecomment -20311034

Я прочитал /bin/_mocha.js и немного поинтересовался --watch.

var watchFiles = utils.files(cwd, [ 'js' ].concat(program.watchExtensions));

Когда мы выполняем mocha-cli с --watch в рабочей области, watchFiles содержит целые файлы в рабочей области. Итак, я попытался отредактировать _mocha.js вручную, как это, и "Test-Runs-Twice Problem" казался подавленным.

Например…

_mocha.js:

  //var watchFiles = utils.files(cwd, [ 'js' ].concat(program.watchExtensions));
  var ext = ['js'].concat(program.watchExtensions);
  var watchFiles = [];
  watchFiles = program.args.map(function(t) {
    return utils.files(resolve(t), ext)[0];
  });
  watchFiles = watchFiles.concat(utils.files(resolve('my/source/code/directory/'), ext));
command line:
 mocha -S -w  ./test/**/*

Это может быть ключом к решению некоторых проблем с --watch.

Я собираюсь закрыть это, так как ясно, что достаточно людей используют --watch что это будет чрезвычайно разрушительно.

Однако он действительно нуждается в капитальном ремонте.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

wzup picture wzup  ·  3Комментарии

robertherber picture robertherber  ·  3Комментарии

eschwartz picture eschwartz  ·  3Комментарии

luoxi001713 picture luoxi001713  ·  3Комментарии

Swivelgames picture Swivelgames  ·  3Комментарии