Mocha: отказ от глобальных объявлений

Даже если бы он просто вывалил свое дерьмо по всему миру, когда вы require('mocha') , было бы лучше, чем текущее положение вещей.

Не думаю, что это глупо, но есть компромиссы со всем. Я был бы доволен примерно таким:

var Mocha = require('mocha');
var mocha = new Mocha(options);
mocha.describe('blah blah', function....

никто не стал бы его использовать, но, по крайней мере, это был бы более чистый способ реализовать то, что у нас есть сейчас. Там будет тонна шаблонов, которые каждый должен будет настраивать каждый раз, но если бы мы могли сузить их до API-интерфейсов CLI, это было бы нормально. Даже если был lib / cli.js, который только что прошел в ARGV, но я все еще сомневаюсь, что кто-то будет его использовать, вы можете использовать его без CLI достаточно легко, но это показывает, что никто действительно не хочет выходить за рамки некоторых крайних случаев.

@visionmedia , кажется, неплохо. Причина, по которой я предложил require("mocha/bdd") или что-то подобное, заключается в том, что это было бы довольно легко реализовать с точки зрения существующего Mocha, но да, ваш, вероятно, лучше. (Вы можете представить себе его использование, например, для одновременного запуска нескольких наборов тестов или чего-то еще. Что ж, это, вероятно, сломается из-за использования process.on ('uncaughtException'), но вы понимаете, что я имею в виду.)

Я могу попробовать сделать это однажды.

Это отличный пример, когда небольшой будущий JavaScript через деструктурирующее присваивание имеет большое значение.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_% 28Merge_into_own_page.2Fsection% 29

var [describe,it,beforeEach,afterEach] = new require("mocha")(options);

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

Это идея, чтобы уметь делать

node test/a-mocha-test.js

И он провел этот тест?

@glenjamin ага

Попытавшись сделать это сам на nodepec, проблема заключалась не в том, чтобы сделать доступными различные функции, проблема заключалась в том, чтобы выяснить, как и когда начать выполнение - нам все равно нужен двухпроходный подход определения / выполнения.

Я придумал следующие варианты:
1) пусть каждый пользователь добавляет что-то вроде mocha.exec () в конец каждого файла, который они могут захотеть запустить изолированно
2) Подождите, пока ядро ​​добавит что-то вроде process.on ('exit'), но когда цикл событий все еще доступен
3) предположить, что каждый файл имеет только один блок описания верхнего уровня, и начать выполнение, когда это закончится

(1), вероятно, самый красивый, который может выглядеть так:

var run = require('mocha/required');

describe('blah blah' , function() {
// ..
});

run();

Похоже, что это не добавляет ничего особенного к выполнению node ./node_modules/.bin/_mocha test/a-mocha-test.js когда вам действительно нужно работать без оболочки mocha .

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

Если кому-то это все еще интересно, не стесняйтесь комментировать или предлагать пул-реквест, и мы рассмотрим :)

Можно ли открыть его снова? Я все еще очень заинтересован в этом. Невозможность всего лишь node test.js тестов мокко была одной из основных причин, по которой я и мои коллеги из Mapbox перешли от мокко к ремням, таким как лента и тап. Лично я предпочел бы придерживаться мокко, но считаю этот аргумент "способности узла" несколько убедительным.

Изменить: аргумент «способность узла» был разработан @tmcw здесь .

Для ясности, отсутствие интерфейса require able здесь не является основным препятствием с точки зрения пользователя. Следующее уже задокументировано для работы:

var describe = require('mocha').describe;
var before = require('mocha').before;
var it = require('mocha').it;

А с ES6 становится еще лучше:

import { describe, before, it } from 'mocha';

Проблема в том, что это работает только при запуске через двоичный файл mocha .

О, спасибо за разъяснения. :) Если мы уже предлагаем эту возможность при запуске с использованием двоичного файла mocha, я согласен, было бы неплохо сделать то же самое с node. Посмотрим на это. Спасибо!

Теперь у этого узла есть перехватчик beforeExit, и это кажется вполне выполнимым.

Должно быть что-то вроде

var { describe, it } = require('mocha/auto')

Да уж. Как сказал TJ, проблема в том, что даже если мы сделаем все «доступным для узлов», для этого может потребоваться слишком много шаблонов, чтобы быть полезным.

Однако...

@glenjamin, спасибо за beforeExit . Я думаю, мы могли бы это использовать. Люди, наверное, до сих пор жаловались бы, что это слишком "волшебство" ...

Я добавил доказательство концепции в 3cdd4a04c48193cceac6af7db72af06d380014a9

в любом случае, это потребует некоторой работы, но я думаю, что мы можем легко обобщить это для всех интерфейсов. здесь нет поддержки Growl, mocha.opts или других вещей, связанных с process таких как коды выхода. Мы должны извлечь код из bin/_mocha и использовать его здесь. Тогда у нас также может быть аргументированная поддержка. Например:

$ node test/my-test.js --reporter=dot

Если у кого-то есть предложения, дайте мне знать

Я думаю, что извлечение некоторых вещей из bin/_mocha в какой-то CLI было бы довольно разумным независимо от этого.

Я все еще не уверен, что это действительно полезное дополнение?

Есть ли большая практическая разница между одним из следующих?

node test/test.js
./node_modules/.bin/mocha test/test.js
PATH=./node_modules/.bin:$PATH mocha test/test.js
npm test -- test/test.js

У меня такое ощущение, что люди, которые не используют мокко, потому что они не могут запускать тестовые файлы через node , просто люди, которые не любят мокко и ищут оправдание! Мокко не обязательно должно быть для всех: smile:

Тоже самое. Я использую jspm и SystemJS и не могу использовать import Mocha в своих тестах, выполняемых в браузере.

import { describe, before, it } from 'mocha';

Не может использоваться в браузерах.

@glenjamin, это просто должно произойти. У Mocha должен быть основной программный API. Хорошим побочным эффектом этого являются тесты с поддержкой узлов. Среда, в которой он работает, будет использовать программный API, будь то браузер, интерфейс командной строки или что-то еще. Mocha.app, кто-нибудь? :)

Интересует эта функция!

+1 за:
import { describe, before, it } from 'mocha';

В настоящее время у нас есть const {describe, it} = require('mocha') , но в этом нет необходимости, потому что глобальные переменные уже существуют.

Если нас интересует поддержка браузера, мы всегда можем сделать const {describe, it} = window.mocha . Мы уже должны сделать это для chai .

ну, я полагаю, const {describe, it} = window тоже.

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

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

исполняемый файл mocha продолжит использовать глобальные переменные; это, вероятно, никогда не изменится.

то, к чему мы можем (и должны) стремиться, - это возможность легко запускать тесты мокко через node не загрязняя глобальное пространство имен. вот о чем этот выпуск.

к сожалению, это клубок шпагата размером с Техас, ни у кого не было времени или энергии, чтобы распутать его, что должно быть очевидно по возрасту проблемы ...

исполняемый файл mocha продолжит использовать глобальные переменные; это, вероятно, никогда не изменится.

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

скорее всего так!

Я на самом деле еще раз взглянул на код, выяснил (более или менее), что я сделал не так в прошлый раз, когда пытался взломать глобальные объекты, подумал о том, что нужно, чтобы тестовые файлы запускались с node test/someFile.js , и полагаю, что знаю, как сделать и то, и другое - с оговоркой, что выполнение этого без утроения числа крайних случаев, вероятно, потребует нарушения некоторых существующих крайних случаев. Более подробно мои мысли по поводу дизайна:

• избегая глобалов
  
  
  
  • Даже в семвере мажоре мы не можем нарушить подавляющее большинство случаев использования Mocha, которые используют глобальные переменные. Вся команда могла бросить свою дневную работу, никогда больше не спать, потратить на нее остаток своей карьеры и по-прежнему буквально не иметь достаточно человеко-часов, чтобы справиться с невообразимым потоком запросов на поддержку, который повлечет за собой. Следовательно: это навсегда останется за флагом .
  
  
  • В настоящее время интерфейсы BDD и TDD имеют особый корпус: оба будут экспортированы (и никакие другие интерфейсы) как require("mocha").it et al. (Примечание: причина, по которой это не нарушается при выборе других интерфейсов, может заключаться в том, что в Mocha есть ошибка, при которой в большинстве случаев он настраивает интерфейс BDD, даже если выбран другой. # 2207) Я хочу отойти от этого.
  
  
  • Пользовательские (сторонние) интерфейсы должны уметь работать со схемой экспорта (при условии, что они используют созданный объект контекста вместо жесткого кодирования global ).
  
  
  • Мы не можем иметь каждый возможный интерфейс, добавляющий свои функции в Mocha (что экспортирует require("mocha") ).
  
  
  • Если мы когда-нибудь исправим ошибку, при которой интерфейс BDD всегда настроен, будет сложно продолжить экспорт интерфейсов BDD и TDD на Mocha , выбран другой интерфейс.
  
  
  • В любом случае вам не следует настраивать пользовательский интерфейс Mocha на TDD и использовать интерфейс BDD или наоборот, если только вы не выполните require("mocha/tddInterface").test или require("mocha/interface/bdd").it (не путать с "mocha/lib/interfaces/<interface name>" где реализации живут).
  
  
  • Мы могли бы, если возможно, сохранить поведение export-BDD-and-TDD-on-Mocha-on-Mocha для обратной совместимости до семер-мажора. Я не ожидаю, что многие люди будут жаловаться, когда мы откажемся от него, учитывая, что люди, которые запросили и используют его, знают о том, что они делают, больше, чем большинство, и в любом случае не полностью удовлетворены этим (поскольку глобалы все еще существуют).
  
  
• возможность узла, то есть возможность запускать node test/someFile.js вместо mocha test/someFile.js
  
  
  
  • Хотя он менее распространен, чем глобальные, я не думаю, что мы можем позволить себе сломать людей, которые используют var Mocha = require("mocha"); var mocha = new Mocha() и т. Д. (То есть «программный интерфейс»). Нам нужно было бы либо обнаружить это и не запускать Mocha «способ с поддержкой узлов», либо (проще для нас, но требует согласия пользователей) потребовать, чтобы возможность доступа к узлам была доступна через другой импорт, например require("mocha/nodeable").it ( .describe и т. Д.). Специальный импорт вместо совмещения с require("mocha") было бы проще реализовать безопасно и соответствовал бы моему желанию (описанному и оправданному в разделе, посвященном предотвращению глобальных переменных) отказаться от экспорта интерфейсов в объекте Mocha экспортировано require("mocha") .
  
  
  • Чтобы иметь возможность node test/someFile.js , недостаточно того, чтобы someFile.js мог импортировать интерфейс Mocha: Mocha должен быть создан, и после того, как все тесты настроены, Mocha должен запуститься. Другими словами, require("mocha/nodeable") должен создать экземпляр Mocha, а также экспортировать интерфейс, а затем ... после запуска тестового файла он должен запустить Mocha.
  
  
  • Один из способов сделать это - запустить Mocha в process.on("beforeExit" , при условии, что тестовый файл не запускает никаких асинхронных действий.
  
  
  • Другой способ сделать это - запустить Mocha в process.nextTick или setImmediate или setTimeout(..., 0 /* or some small number */) .
  
  
  • Тесты, которые устанавливают свои данные с помощью --delay и асинхронно запускаются с помощью run() , будут проблемой. Не для того, чтобы знать, когда бежать - это проще, есть run() - и даже не для того, чтобы знать, нужно ли --delay (см. Ниже или предоставить require("mocha/nodeable/delayed") ), а потому, что run() Предполагается, что run() в любом случае должен вызываться в каждом тестовом файле, и в этом случае использовать его с тестами с поддержкой узлов будет легко после исправить это. В противном случае ... Я не знаю, что мне делать.
  
  
  • Если мы хотим иметь возможность вызывать эти тестовые файлы через mocha вместо node (т.е. использование этого не приводит к принудительному использованию node ), тогда все, что есть require d должен определять, когда используется CLI, и не создавать Mocha. Это было бы проще, чем обнаруживать, когда используется программный API - интерфейс командной строки может установить какое-то глобальное состояние, которое эти модули будут проверять, или эти модули могут проверить, является ли CLI файлом, который запускал Node.
  
  
  • Нам нужно было бы сделать части интерфейса командной строки более модульными, если бы мы хотели поддерживать передачу флагов Mocha при работе через Node, или используя mocha.opts , или что-нибудь, что позволяло бы тестовым файлам с поддержкой узлов использовать поведение, отличное от стандартного для Mocha. поведение.
  
  
• Объединив ограничения этих двух идей, я предлагаю (и считаю, что могу реализовать) :
  
  
  
  • избегая глобалов
  
  
  • Вместо того, чтобы передавать интерфейсам объект global для размещения их функций, он передает им «выбранный объект интерфейса». (ИЗМЕНЕНО, ЧТОБЫ ДОБАВИТЬ: это должно быть сделано как в lib/mocha.js и в browser-entry.js . Насколько мне известно, все части предложения, относящиеся к глобальному, выполняются как в Node, так и в браузере. )
  
  
  • После этого он скопирует все содержимое выбранного интерфейсного объекта в global .
  
  
  • Параметр localInterface ( --local-interface в интерфейсе командной строки) остановит Mocha от копирования из выбранного интерфейсного объекта в global .
  
  
  • DEBATABLE: Изначально для обратной совместимости с require("mocha").it Mocha также скопирует функции TDD / BDD из выбранного интерфейсного объекта в Mocha , но позже это будет объявлено устаревшим / удалено.
    
    
    
    
    
    • (ПРИМЕЧАНИЕ: если мы остановим настройку BDD, когда он не выбран, нам, возможно, придется сделать здесь еще более специальную обработку, чтобы настроить BDD на фиктивный выбранный объект интерфейса, из которого они могут быть скопированы - хороший случай для удаления поведение в целом, оно становится тем сложнее, чем больше других вещей мы исправляем / улучшаем, все еще пытаясь поддержать это.)
    
    
    
  
  
  • require("mocha/interface") экспортирует выбранный интерфейсный объект.
  
  
  • require("mocha/interface/<specific interface>") вызовет указанный интерфейс с новым выбранным объектом интерфейса, который он впоследствии будет экспортировать.
  
  
  • ИЗМЕНЕНО ДЛЯ ДОБАВЛЕНИЯ: require("mocha/interface") также будет свойством объекта mocha в браузере, mocha.interface , для поддержки использования браузера без модульной системы.
  
  
  • способность узла
  
  
  • require("mocha/nodeable/<specific interface>") создаст экземпляр Mocha, настроит Mocha для запуска после тестового файла (предположительно с использованием setTimeout если не используется delay , см. Выше re. delay ) и экспортировать выбранный объект интерфейса для этого интерфейса так же, как require("mocha/interface/<specific interface>")
  
  
  • Если параметры CLI или mocha.opts поддерживаются, require("mocha/nodeable") создаст экземпляр Mocha, настроит Mocha для запуска после тестового файла (см. Выше) и выполнит те же действия по настройке интерфейса, что и CLI, экспортируя выбранный интерфейсный объект точно так же, как require("mocha/interface") .
  
  
  • Если мы хотим, чтобы тестовые файлы с поддержкой узлов также были доступны для mocha тогда mocha/nodeable & mocha/nodeable/<specific interface> не требуется, мы можем использовать возможности узла для mocha/interface & mocha/interface/<specific interface> .
  
  

Мысли?

На самом деле, после дальнейшего размышления, я предлагаю закрыть этот билет по следующему обоснованию против использования node <test file> вместо mocha <test file> :

• Я не знаю, какие преимущества он предлагает.
  
  
  
  • Одна из возможных идей состоит в том, что он запускает только один тестовый файл независимо от того, какие глобусы находятся в mocha.opts . Простое решение: положить шарики в test сценария в package.json вместо: npm test будет работать все из них и mocha ( node_modules/.bin/mocha , npx mocha ) запустит только указанные тестовые файлы. (Файлы или глобусы, которые должны запускаться для любого тестового запуска, независимо от того, сколько тестовых файлов запущено, все равно должны входить в mocha.opts .)
  
  
  • Другая возможная идея состоит в том, что он позволяет полностью обойти mocha.opts . Теперь это должно быть достигнуто с помощью mocha --opts /dev/null (или в Windows mocha --opts nul ). Если по какой-то причине это не так, было бы проще реализовать флаг CLI, чтобы пропустить обработку mocha.opts .
  
  
• Это может быть реализовано вне Mocha; вместо "mocha/nodeable" просто поместите тот же код с использованием программного API Mocha в гипотетический пакет "nodeable-mocha" .
  
  
  
  • Я не говорю , что это будет легко реализовать в первую очередь, я говорю , я не знаю ни одного способа это может быть более трудно реализовать из - за находясь вне мокко.
  
  

Если мы обнаружим какое-либо существенное преимущество, которого легче достичь в основном, чем за его пределами, мы всегда можем открыть его заново.

Тем не менее, я также предлагаю повторно открыть заявку на избегание глобальных переменных, потому что:

• Хотя преимущества вряд ли будут актуальными (сколько других библиотек используют глобальные объекты с именами describe , it и т. Д.?), Они возможны в принципе (ответ на этот вопрос мог бы быть более точным. чем 0, хотя и немного) - теоретически то, что нужно делать, не выгружать содержимое в глобальное пространство имен.
  
  
  
  • Более того, в моем плане такое же поведение было бы распространено на сторонние интерфейсы, которые правильно написаны для использования испускаемого «контекстного» объекта (для которого Mocha в настоящее время всегда использует глобальный объект), а не жесткого кодирования глобального объекта; хотя кажется, что наши собственные интерфейсы вряд ли будут мешать работе других библиотек, мы не можем дать никаких гарантий относительно других интерфейсов, поэтому мы также упростили бы им поступление правильных вещей.
  
  
• В моем плане было бы убрать множество связанных крайних случаев в текущем поведении (например, распространить его на сторонние интерфейсы, но также обеспечить согласованность в Mocha вместо специального оформления интерфейсов BDD и TDD).
• Единственный простой способ реализовать его за пределами Mocha - использовать программный API Mocha и исправить его , и это оставит некоторые из вышеупомянутых несоответствий и крайних случаев.

поэтому вы предполагаете, что Mocha предоставляет способ запускать тесты с mocha но с флагом, который не загрязняет global ?

Часть того, что делает мокко-мокко, и часть его успеха заключается в том, что он не требует шаблонов для импорта. Несмотря на догму о загрязнении глобального пространства имен, есть вполне веские причины для этого с точки зрения эргономики разработчика.

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

Ага.

Часть того, что делает мокко-мокко, и часть его успеха заключается в том, что он не требует шаблонов для импорта. Несмотря на догму о загрязнении глобального пространства имен, есть вполне веские причины для этого с точки зрения эргономики разработчика.

Я не говорю, что в целом не согласен, но в качестве дополнительной функции я вижу, где некоторые разработчики могут захотеть импортировать вместо глобальных (возможно, они хотят, чтобы их модуль называл локальную переменную context не ссылаясь случайно к глобальному, если они забудут var , возможно, они захотят использовать сторонний интерфейс, где такое столкновение еще более вероятно), и теперь, когда я понял, как это сделать правильно, также легче сделать в Mocha, чем как какое-то дополнение (на самом деле, если меня не увлечет что-то еще, я, вероятно, на этой неделе добавлю черновик в ветке, чтобы продемонстрировать).

(Кроме того, мы уже поддерживаем своего рода попытку, когда после настройки интерфейса на глобальном уровне он копируется в объект Mocha так что вы можете require("mocha").it , но версия, которую мы уже откровенно говоря, поддержка - это странно, непоследовательно , подвержено ошибкам и даже фактически не позволяет избежать загрязнения глобального пространства имен. Если мы вообще собираемся сохранить такую ​​функцию, мы можем исправить ее, а не поддерживать сомнительную версию.)

Это ИМО в отличие от возможности node <test file> для тестов Mocha, которые, насколько мне известно, не имеют никаких преимуществ и их было бы одинаково сложно реализовать как внутри, так и за пределами Mocha.

@stevenvachon
почему у меня const {describe, it} = require('mocha') не работает? Я только что получил неопределенное ...

$ node -v
v8.4.0

@zapphyre, вам по-прежнему нужно запускать набор тестов через программу mocha , а не через node .

Вы не можете запускать несколько исходных файлов с помощью node , поэтому вы застряли с mocha . Я не знаю тестового раннера / фреймворка, у которого нет собственного исполняемого файла.

Обновлен заголовок проблемы, чтобы быть более конкретным

Другая причина для этого: я хотел бы запускать тесты, используя другую среду выполнения JS, например low.js (потому что это одна из наших платформ, другие - node.js, браузер и React Native). Я могу сделать это, когда у меня есть JS-файл, который импортирует мокко и запускает тесты, я не могу этого сделать, когда мне нужно вызвать mocha для запуска тестов.

Я имею в виду, вы уже делаете это для браузера. На этой платформе у меня есть JS-код, который импортирует «мокко», а затем запускает тесты из глобального объекта mocha используя mocha.run() .

В браузере я

• Загрузите мокко и получите глобальный объект mocha
• Выполнить mocha.setup({ui: 'bdd'});
• Загрузите все тестовые файлы с помощью SystemJS
• Тогда я бегу

      mocha.checkLeaks();
      mocha.globals([]);
      mocha.run();

Вот и все. Когда я пробую то же самое в node.js, используя оператор require вместо SystemJS для загрузки тестового файла, я получаю (используя mocha 5.2.0)

> mocha.run();
TypeError: Cannot read property 'search' of undefined
    at Mocha.mocha.run (/home/mha/one/node_modules/mocha/mocha.js:149:54)

РЕДАКТИРОВАТЬ: я пробовал https://github.com/mochajs/mocha/wiki/Using-Mocha-programmatically и mocha.addFile вместо того, чтобы просто загружать его, результат тот же.

Есть ли в настоящее время способ импортировать описание / это?

Существует новая (на данный момент 20-часовая) страница Wiki https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically, но она предназначена для запуска тестов.

Другая причина для этого: я хотел бы запускать тесты, используя другую среду выполнения JS, например low.js (потому что это одна из наших платформ, другие - node.js, браузер и React Native). Я могу сделать это, когда у меня есть JS-файл, который импортирует мокко и запускает тесты, я не могу этого сделать, когда мне нужно вызвать mocha для запуска тестов.

Если альтернативная среда выполнения имеет исполняемый файл, похожий на узел (что, я думаю, есть в low.js?), Тогда вы можете сделать alternative-executable ./node_modules/.bin/_mocha , и это должно сработать.

Я не знаю тестового раннера / фреймворка, у которого нет собственного исполняемого файла.

https://github.com/tapjs/node-tap/#tutti -i-gusti-sono-gusti

Теперь, когда https://github.com/mochajs/mocha/issues/3006 разрешен, было бы неплохо иметь в браузере экспорт с тем же именем.

В настоящее время работает:

<script type="module">
  import './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

Но этого нет:

<script type="module">
  import { mocha } from './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

(по запросу https://github.com/mochajs/mocha/issues/956#issuecomment-167453800)

Это может стать проще, если мы объединим нашу ветку со сворачиванием и настроим транспилеры. Кажется возможным иметь пакет esm и унаследованный пакет, который использует пути кода esm и добавляет глобальные утечки. Нам пришлось бы проявить большую осторожность, чтобы вносить изменения только в недавно добавленные пути и пакеты кода, чтобы мы не ломали или кодировали как в браузерах, так и в узле

С глобальными переменными и типами это просто делает мокко унаследованным.

Кстати, только что создал @types/mocha без глобальных переменных: https://github.com/whitecolor/mocha-types

Надеюсь, они (глобалы) скоро будут официально удалены.