Вы можете лучше создать два параллельных каталога, один для тестов, а другой
для файлов данных. Я так и сделал.
Am 04.03.2015 15:52 schrieb "Kyle P Davis" [email protected] :

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

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

Мысли? Если хотите, я могу быстро устроить пиар.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mochajs/mocha/issues/1577.

Я мог бы (и делал это раньше), но я бы предпочел не делать этого больше сейчас, когда я понял, что игнорирование glob прямо здесь.

Должно быть довольно легко добавить аргумент командной строки, чтобы установить параметр игнорирования glob. Я просто хотел сначала подумать и немного обсудить.

Есть ли возражения против того, чтобы я создавал для этого пиар?

Мне это тоже было нужно, и я был удивлен, увидев, что у мокко его еще не было. Думаю, это было бы отличным дополнением. Внутри нашей тестовой папки есть «testApp», который мы используем специально для тестирования. Мы не хотим, чтобы мокко пытался запускать тесты внутри этой папки. Было бы неплохо иметь возможность просто добавить исключение в наш файл mocha.opts, чтобы исключить этот конкретный путь, вместо того, чтобы явно включать все другие тестовые подпапки, которые у нас есть.

Хотя мы могли переместить testApp, оно действительно не помещается ни в одном другом репозитории и имеет относительный путь к определенным файлам в тестовой папке.

Думаю, это было бы хорошим дополнением. Конечно не критично, но полезно.

@KylePDavis @toddbluhm

Если бы мне это было нужно, я бы, наверное, просто

$ mocha $(find test/ ! -path '*testApp*')

Так что я не в восторге от этой идеи. Я как бы сомневаюсь в существовании флага recursive , поскольку то же самое можно сделать с помощью команды оболочки Makefile , Gruntfile.js , gulpfile.js и т. Д. И т. Д.

Я думаю, что @boneskull хорошо

$ tree .
.
└── spec
    ├── fixtures
    ├── integration
    └── unit

4 directories, 0 files

Вы просто обновляете свой package.json, чтобы вы могли просто запустить npm test

  "scripts": {
    "test": "mocha spec/unit spec/integration"
  }

Или со структурой, подобной следующей:

$ tree .
.
└── src
    └── models
        ├── user.js
        └── userSpec.js

2 directories, 2 files

Вы можете запускать спецификации аналогично примеру @boneskull (это будет запускать только файлы, содержащие Spec )

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Изменить: исправлено :)

@danielstjules Я думаю, что это действительно попадет в любой Spec в имени. Возможно, вы хотите -name '*.spec.js'

Ага, ты прав! Brainfart. Спасибо что подметил это.

Фиксированная команда для примера:

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Я думаю, что для этой функции все еще существует допустимый вариант использования: я обычно группирую свои файлы по функциям, поэтому каждый тестовый файл находится рядом с файлами, содержащими логику, которую они тестируют. Именование тестовых файлов последовательно работает с аргументом file или параметром grep но я хотел бы явно игнорировать такие вещи, как node_modules .

Для всех, кто ищет - gulp-mocha может добиться этого, я просто ненавижу включать gulp там, где мне это не нужно.

Я хотел бы воспользоваться моментом и добавить +1 к этой идее. В отличие от типичных проектов JavaScript, мне нравится следовать тому, как GO выполняет модульное тестирование, и я включаю файл спецификации рядом с каждым файлом, который проходит тестирование. Например, каталог в одном из моих проектов может выглядеть следующим образом:

main.js
main.spec.js
utilities.js
utilities.spec.js

Я считаю, что такой тип организации значительно упрощает поиск тестов по сравнению с копанием в единственном каталоге файлов тестов; вы всегда ожидаете, что тест будет располагаться рядом с файлом, который он тестирует, а мой скрипт сборки выполняет сценарии для всех файлов .spec.js в развернутой версии.

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

В настоящий момент у меня нет бокса с Windows рядом со мной, но я не уверен, будет ли этот синтаксис find работать в Windows или нет; В любом случае, на мой взгляд, вариант исключения был бы гораздо более интуитивным. Кроме того, почти все фреймворки модульного тестирования включают способ игнорирования файлов, так что четность была бы хорошей.

Привет, все мои тесты поддерживают формат *.test.js . Все они находятся в каталоге tests . В настоящее время у меня есть несколько тестов, которые я хочу исключить, и все же сохранить путь по умолчанию для мокко, который равен ./test/**/*.js . Как я могу это сделать?

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

@calebthebrewer К счастью, я использую в проекте

+1 @calebthebrewer

В Angular 2.0 и Polymer я работаю в компонентном режиме, поэтому я согласен с @KrisSiegel. Хранение всего кода в пакетах обеспечивает чистую, модульную и простую в обслуживании иерархию файлов.

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

import q from 'q';

import authRouterTest from '../app/routes/_authentication.router.e2e.js';

import productRouterTest from '../app/routes/_product.router.e2e.js';

import productModelTest from '../app/models/product.model.spec.js';

// Dynamically constructed sequence of functions
let funcs = [ productModelTest(), authRouterTest(), productRouterTest() ];

// This function takes an array of promise-producing functions and
// runs them sequentially.
let execTests = () => {

    let result = q();

    funcs.forEach((f) => {

        result = result.then(f);
    });

    return result;
};

// Execute tests
execTests();

Таким образом, вы можете импортировать файлы откуда угодно и иметь только один тестовый файл в test/ .

Вы можете разрешить обещание в последнем тестовом блоке и завершить каждый тест следующим образом

import q from 'q'

export default () => {

    let Q = q.defer();

    describe('something', () => {

        it('should', (done) => {

            ...
        });
    });

    describe('something', () => {

        it('should', (done) => {

            ...
        });

        it('should', (done) => {

            ...

            Q.resolve('test complete');
        });
    });

    return Q.promise;
};

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

Мы все еще должны игнорировать глобус. Использование команд bash не является кроссплатформенным решением.

+1

Я действительно хотел бы исключить node_modules . Exclusion кажется довольно удобным компаньоном для recursive .

@godspeedelbow Почему этот конкретный каталог нужно явно игнорировать? Обычно я не слышу о том, что node_modules находится в тестовом каталоге.

FWIW, я тоже мог бы это использовать. У меня есть пара проектов, в которых тесты масштабируются намного больше, чем сама библиотека, и это позволило бы мне лучше их организовать (фикстуры принадлежат тестовой директории IMHO).

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

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

@KrisSiegel Вы всегда можете использовать src/**/*.js и src/**/*.spec.js . Я наблюдаю это чаще в проектах Go и Rust, чем в корне проекта. На самом деле последнее относительно редко.

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

Я не очень заинтересован в этом лично, потому что на самом деле я работаю над собственной тестовой структурой, призванной стать полной альтернативой Mocha, Jasmine, Tape и т. Д., Хотя по своей сути более простой и мощный. Впрочем, это еще слишком большая работа для даже игрушечных банкоматов.

Я использую Mocha для эффективной загрузки фреймворка. Сначала я использовал Chai для утверждений, пока они не стабилизировались (сейчас они практически заблокированы API, поскольку я использую утверждения фреймворка для тестирования).

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

Исключить - довольно простой шаблон, который есть во многих утилит. Думаю, мокко это нужно :). Хотя я предполагаю, что у меня сложилось впечатление, что, поскольку эта проблема была закрыта на основе обходных путей, специфичных для платформы, это нежелательно по сравнению с ожиданием патча. Если это то, чего на самом деле хотят люди, готовящие мокко, то, если это не будет сделано в течение нескольких недель, я определенно смогу сделать патч.

@KrisSiegel Я почти уверен, что, если бы кто-то действительно запустил патч, он, вероятно, был бы объединен, если он не включает какой-то неинтуитивный, специальный синтаксис или дополнительный флаг. FWIW, еще не было PR для _this_, и причина, по которой эта проблема была закрыта, была довольно слабой, если вы считаете, что это зависит от find только для того, чтобы запустить несколько тестов.

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

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

Возможность указать файлы для игнорирования с помощью .mochaignore или другого варианта была бы идеальной, так как в этом случае я мог бы просто запустить его с помощью **/*.spec.js glob и не беспокоиться о том, что он может включать тесты из node_modules папка.

Почти все другие инструменты сборки позволяют это сделать, у нас есть .npmignore , .gitignore , .jshintignore , а jscs предоставляет возможность настроить его через .jscsrc . Было бы полезно, если бы Mocha также поддерживал его, так как все больше и больше людей движутся в сторону организации файлов компонентов / функций и папок, отходя от подхода с ящиком для носков.

@isiahmeadows, как и другие, упомянутые, я застрял в структуре папок, которую я не могу легко изменить, поэтому services/ , routes/ и т. д. находятся в корне проекта точно так же, как node_modules есть. Меня вдохновило поместить тестовые файлы рядом с файлами, которые они тестируют. Это действительно отлично работает, но мне нужен третий инструмент (будь то командная строка, gulp или что-то еще), чтобы исключить node_modules чтобы тестировались только мои собственные тесты.

Я бы сам реализовал это в мокко, если бы знал с чего начать :)

@godspeedelbow @adambuczynski Временное решение :)

  "scripts": {
    "test": "mocha $(find . -name '*.spec.js' ! -ipath '*node_modules*')"
  }

Привет, @danielstjules, спасибо! Пробовал, но по какой-то причине find . -name '*.spec.js' ! -ipath '*node_modules*' находит только один тестовый файл.

Вы обновили '*.spec.js' в соответствии с шаблоном, которому следуют ваши тесты? Например, чтобы сопоставить _все_ js файлы, вы должны использовать:

  "scripts": {
    "test": "mocha $(find . -name '*.js' ! -ipath '*node_modules*')"
  }

@danielstjules приветствует, но я считаю, что это не сработает в Windows, и хотя для этого приложения это не проблема, я не решаюсь добавить его.

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

@danielstjules да, все тестовые файлы имеют формат *.spec.js . Раньше почему-то не работало, а теперь, когда без проблем. Спасибо за эту работу * NIX.

Я хочу, чтобы это было сделано для предстоящего майора; конкретно поддержка .mochaignore кажется мне разумной

@boneskull Спасибо, было бы здорово.

В следующем крупном выпуске не могли бы вы также рассмотреть реализацию более "стандартного" .mocharc для передачи параметров, который можно поместить в корень проекта, вместо того, чтобы использовать mocha.opts в папке test ?

Это сделало бы настройку Mocha намного проще и в соответствии с тем, как это делается с другими инструментами. Кроме того, это не заставит нас создать папку test только для mocha.opts . (Мы помещаем все наши тесты вместе с тестируемыми модулями).

@adambuczynski абсолютно. Я не фанат mocha.opts

@adambuczynski отличный комментарий. Я согласен, я бы тоже хотел иметь стандартный файл опций .mocharc, я тоже больше не использую тестовый каталог, так как так приятно держать тесты рядом с кодом.

+1, думаю, что исключить действительно нужно.

@adambuczynski @boneskull В документации указано, что вы можете использовать --opts для указания любого пути к вашему файлу opts, хотя в ней не приводятся примеры. Я использую это в своем текущем проекте и могу подтвердить, что он работает как mocha --opts .mocharc

Спасибо @GRUBES. В конце концов, я продолжал использовать папку test потому что я помещаю туда свои помощники по настройке теста, но хорошо знать, что это возможно.

Glob имеет опцию игнорирования, поэтому не должно быть большого труда просто добавить опцию исключения и перенаправить ее игнорировать glob.

ignore Добавить шаблон или массив шаблонов глобусов для исключения совпадений. Примечание: шаблоны игнорирования всегда находятся в режиме точка: правда , независимо от любых других настроек.

Не знаю, почему на это уходит больше года. :-)

@ inf3rno Кстати, это, вероятно, было бы решено намного раньше, если бы кто-то действительно сел и написал патч.

@isiahmeadows Да , но это не я. : D

Так нужен ли еще пиар? Я был бы рад добавить это, так как я бы предпочел использовать совместное размещение тестовых файлов вместо нескольких каталогов для test и test-integration

2036, который в основном предназначен для тех же самых общих вещей, только файл, а не параметр командной строки, имеет PR # 2173

Может быть, неплохо добавить такую ​​опцию, как --exclude .

Или поддержите что-то вроде mocha test/*.js !test/_*.js

Фигурный Glob out: mocha "./{,!(node_modules)/**/}*.test.js" чтобы получить все файлы * .test.js, кроме node_modules, и mocha "./test/**/!(notThisOne).js" чтобы получить все в тестовой папке и подпапках, кроме notThisOne.js

Смотрите также:
https://github.com/isaacs/node-glob#glob -primer
https://github.com/isaacs/node-glob/issues/62

@ScottFreeCode

При запуске в терминале я получаю

mocha "./{,!(node_modules)/**/}*.test.js"
-bash: !: event not found

Следует ли сбежать от этого персонажа?

@mdumouchel Используйте одинарные кавычки. В противном случае - да.

@isiahmeadows

По-прежнему возникает ошибка

node_modules/mocha/lib/utils.js:630
        throw new Error("cannot resolve path (or pattern) '" + path + "'");
              ^
Error: cannot resolve path (or pattern) './{,!(node_modules)/**/}*.test.js'

В итоге я просто использовал команду find

mocha $(find . -type d -name node_modules -prune -o -name '*.test.js')

@mdumouchel Если вы используете версию 2.x (то есть то, что есть в npm), она в любом случае работать не будет. Поддержка начнется в 3.x, IIRC.

Это странно, я думал, что пробовал в Bash и смог использовать двойные кавычки. Кто-нибудь знает синтаксис / экранирование, которое будет работать как в Windows, так и в Bash?

Кроме того, я почти уверен, что ошибка «не удается разрешить путь» означает, что путь не соответствует ни одному файлу в вашем проекте; путь, который я указал, работал в текущей версии, когда у меня были тестовые файлы с именами, заканчивающимися на ".test.js" вместе с соответствующими исходными файлами, если я не облажался, скопировав его из моего теста в комментарий к проблеме ...

См. № 2173

Eslint отлично справляется с игнорированием файлов с --ignore-path (и .eslintignore ).
См: http://eslint.org/docs/user-guide/command-line-interface#ignoring -файлы

Что-то подобное для мокко было бы круто: two_hearts:

Мое решение:

eslint "test/!(fixtures)/**/*.js" "test/*.js"

Моя файловая структура

.
└── src
└── test
    └── fixtures
        └── data.js
    ├── foo.js
    └── bar.js

Проблема: Mocha дает мне Error: cannot resolve path (or pattern) если какой-либо из двух путей что-то не соответствует ..

Хорошо, поэтому я уступил. Это просто неудобно для пользователя.

Вот что, я думаю, нам следует делать:

1. Поддержка --exclude <glob-or-path>
2. Поддержка _multiple_ экземпляров --exclude
3. Объедините все параметры --exclude со всеми аргументами без параметров в один список (в основном, что делает globby )
4. Загрузите эти файлы

В настоящее время мы поддерживаем _n_ аргументы без параметров, которые могут быть глобальными, но это только _additive_; это работает не так, как вы ожидаете:

$ mocha 'src/**/*.spec.js' '!src/forbidden/**/*.spec.js'

Таким образом, приведенное выше должно работать, и --exclude на самом деле просто сахар для ! .

Кроме того, поддержка .mochaignore (# 2036) звучит неплохо, но это отдельная проблема. Должен быть модуль 3p, который мы можем использовать, чтобы иметь .gitignore -подобное поведение; Я уверен, что то, что делает ESLint, достаточно для наших целей.

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

Удивительно, но до сих пор нет такой опции, как --ignore-path , кроме помещения всех тестов в папку tests , нет причин, по которым мы не можем помещать тесты вместе с модулями.

+1
игнорировать файлы или каталоги по шаблону - очень полезная функция

@isiahmeadows

Вы всегда можете использовать src / / .js и src / /.spec.js

Нет, не удалось - сопоставление с шаблоном **/* нарушено и не работает рекурсивно.

РЕДАКТИРОВАТЬ: @ScottFreeCode имеет ответ ниже

сопоставление с образцом **/* нарушено и не работает рекурсивно.

Являются ли ваши пути кавычки ?

+1

Как описано в https://github.com/zinserjan/mocha-webpack/issues/124 :

Внутри src/ находится файл с именем server.ts который запускает экспресс-сервер и работает в фоновом режиме. Сервер обычно включен во время работы покрытия, поэтому порт уже используется.

Поэтому мы не хотим исключать этот и только этот файл.

http://remarkablemark.org/blog/2017/02/07/mocha-glob-pattern/

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

Мокко канонично. почему бы не поднять планку для кроссплатформенного набора функций тестовой среды, к которой стремятся все остальные тестовые среды? Мы должны перестать стремиться оставлять все на усмотрение Баша. Уже 2017 год.

Я также отмечу, что у Windows-людей нет ничего эквивалентного Bash !(glob) (который на самом деле является Bash-ism, даже не стандартом POSIX).

Не должно быть никакой зависимости Bash в глобализации Mocha как есть, поскольку она обрабатывается через модуль Glob JS. (Примечание: может потребоваться цитирование путей, чтобы избежать обработки глобусов оболочкой иначе, чем в Mocha, например, ** без расширения globstar или того, что делает это особенным.)

@ScottFreeCode. Используете ли вы extglob: true когда используете glob? Если это так, то это можно закрыть с помощью этого синтаксиса в качестве обходного пути (поскольку glob / minimatch поддерживает его с включенной этой опцией).

Похоже, мы просто проходим путь к glob . Я почти уверен, что в какой-то момент я получил отрицание, работающее через шаблон глобуса, но, возможно, это была более старая версия модуля? В любом случае, у нас есть тесты на поведение двойной звезды , поэтому, если кто-то захочет отправить тесты, чтобы подтвердить, что некоторые шаблоны отрицания тоже работают (или если кто-то обнаружит какие-либо недостатки в уже имеющихся у нас тестах на подстановку), это было бы здорово. .

Однако наличие явной опции ignore / exclude дает определенное преимущество. Фактически, несколько преимуществ:

• менее неясный
• легче избежать столкновений со специальными символами разных ОС и правилами цитирования
• список включения минус список исключения во многих случаях проще, чем список включения с инвертированными частями

Я просто хотел пояснить, что статус-кво не предполагает полагаться на какую-то конкретную оболочку. ; ^)

список включения минус список исключения во многих случаях проще, чем список включения с инвертированными частями

Верно, и я чуть не забыл об этом 😄

Любой, кто подойдет к этому вопросу:

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

Работает ли опция --exclude ?
Не могу найти в документации .

@ sepo-one Я открыл PR, чтобы обновить документ.
Вы можете увидеть все доступные варианты на странице mocha -h .

Да, я использовал старую версию мокко. Модернизировано и есть опция --exclude .
Думаю, в любом случае нужно обновить документы.

Спасибо @outsideris