Mocha: 글로벌 옵트 아웃

require('mocha') 때 전역 공간 전체에 쓰레기를 버리더라도 현재 상황보다 낫습니다.

나는 그것이 어리 석다고 생각하지 않지만 모든 것에 절충점이 있습니다. 나는 다음과 같은 것에 만족할 것입니다.

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

아무도 그것을 사용하지 않을 것이지만 적어도 현재 우리가 가지고있는 것을 구현하는 더 깨끗한 방법이 될 것입니다. 모든 사람이 매번 설정해야하는 _ton_의 상용구가있을 것입니다.하지만 CLI-ish API로 범위를 좁힐 수 있다면 괜찮을 것입니다. ARGV에 방금 전달한 lib / cli.js가 있었지만 여전히 누군가 사용할 것 같지는 않지만 CLI 없이도 쉽게 사용할 수 있지만, 이는 아무도 실제로 일부 엣지 케이스를 넘어서고 싶어하지 않음을 보여줍니다.

@visionmedia 꽤 좋은 것 같습니다. 내가 require("mocha/bdd") 또는 이와 유사한 것을 제안한 이유는 기존의 Mocha 측면에서 구현하기가 매우 쉬울 것이지만 네, 아마도 당신의 것이 더 좋을 것입니다. (예를 들어 한 번에 여러 테스트 스위트를 실행하는 데 사용하는 것을 상상할 수 있습니다. 글쎄요, 아마도 process.on ( 'uncaughtException') 사용으로 인해 깨질 것입니다. 그러나 제가 의미하는 바를 알 수 있습니다.)

언젠가는 풀 리퀘스트를 시도 할 수 있습니다.

이것은 Destructuring Assignment를 통한 약간의 미래 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

그리고 그 테스트를 실행 했습니까?

트윗 담아 가기

nodespec에서 직접이 작업을 시도했지만 문제는 실제로 다양한 기능을 사용할 수있게하는 것이 아니 었습니다. 문제는 실행을 시작하는 방법 /시기를 파악하는 것이 었습니다. 여전히 2 단계 정의 / 실행 접근 방식이 필요했습니다.

내가 생각 해낸 옵션은 다음과 같습니다.
1) 모든 사용자가 격리하여 실행하려는 모든 파일의 맨 아래에 mocha.exec ()와 같은 것을 추가하도록합니다.
2) core가 process.on ( 'exit')와 같은 것을 추가 할 때까지 기다립니다. 그러나 이벤트 루프가 여전히 사용 가능할 때
3) 각 파일에 하나의 최상위 기술 블록 만 있다고 가정하고 완료되면 실행을 시작합니다.

(1) 아마도 가장 좋을 것입니다.

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

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

run();

이것은 mocha 래퍼없이 실행해야 할 때 node ./node_modules/.bin/_mocha test/a-mocha-test.js 를 수행하는 것보다 많은 것을 추가하지 않는 것 같습니다.

나는 이것이 현재 모카가 사용되는 방식과 더 이상 맞지 않는다고 생각합니다. 이 스레드는 1 년 넘게 비활성화되었으므로 지금은 닫습니다.

여전히 이것에 관심이 있다면 자유롭게 의견을 말하거나 풀 요청을 제안하면 고려할 것입니다 :)

다시 열 수 있습니까? 나는 여전히 그것에 매우 관심이 있습니다. node test.js 모카 테스트를 수행 할 수 없다는 것이 저와 Mapbox의 동료들이 모카에서 테이프 및 탭과 같은 하네스로 이동하는 주된 이유 중 하나였습니다. 개인적으로 저는 모카를 고수하고 싶지만 "노드 능력"이라는 주장이 다소 설득력이 있다고 생각합니다.

편집 : "node-ability"인수는 @tmcw here에 의해 정교화 되었습니다 .

명확성을 위해 require 가능 인터페이스가 없다는 것은 사용자 관점에서 볼 때 주요 차단 요인이 아닙니다. 다음은 이미 작동하도록 문서화되어 있습니다.

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

ES6에서는 더 좋아집니다.

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

문제는 이것이 mocha 바이너리를 통해 실행할 때만 작동한다는 사실입니다 .

오, 해명 해주셔서 감사합니다. :) mocha 바이너리를 사용하여 실행할 때 이미이 기능을 제공한다면, 노드에서도 똑같이하는 것이 좋을 것 같다는 데 동의합니다. 그것을 조사 할 것입니다. 감사!

이제 노드에 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 를 통해 테스트 파일을 실행할 수 없기 때문에 모카를 사용하지 않는 사람들은 단순히 모카를 좋아하지 않고 변명을 찾고있는 사람들이라는 느낌이 들었습니다! 모카가 모든 사람을위한 것은 아닙니다.

여기도 마찬가지입니다. jspm 및 SystemJS를 사용하고 있으며 브라우저에서 실행중인 테스트에서 import Mocha를 사용할 수 없습니다.

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

브라우저에서 사용할 때 사용할 수 없습니다.

@glenjamin 그냥 일어날 필요가 있습니다. Mocha에는 핵심 프로그래밍 방식 API가 있어야합니다. 그 좋은 부작용은 노드 가능 테스트입니다. 실행되는 환경은 브라우저, CLI 또는 완전히 다른 것이 든 프로그래밍 방식 API를 사용합니다. Mocha.app, 누구? :)

이 기능에 관심이 있습니다!

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

현재 const {describe, it} = require('mocha') 이 있지만 전역이 이미 존재하므로 필요 하지 않습니다.

브라우저 지원이 염려된다면 언제든지 const {describe, it} = window.mocha 있습니다. 우리는 이미 차이 를 위해 이것을해야합니다.

음, const {describe, it} = window 도 그렇습니다.

이것은 mocha의 아키텍처에 매우 기본이어서 mocha 는 번들로 묶일 때

나는 mocha가 단일 네임 스페이스 이외의 전역을 정의해야한다고 생각하지 않으며 아마도 브라우저에 대해서만 정의 할 수 있습니다.

mocha 실행 파일은 계속 전역을 사용합니다. 그것은 결코 변하지 않을 것입니다.

우리가 시도 할 수있는 (그리고해야 할) 것은 글로벌 네임 스페이스를 오염시키지 않고 node 를 통해 쉽게 mocha 테스트를 실행할 수있는 능력입니다. 그것이이 문제에 관한 것입니다.

안타깝게도 텍사스 크기의 꼬기 공은 아무도 풀지 못했던 시간이나 에너지가 없었습니다.이 문제의 나이가되면 분명해집니다 ...

mocha 실행 파일은 계속 전역을 사용합니다. 그것은 결코 변하지 않을 것입니다.

모카가 어떻게 구성되어 있는지에 대해서는 아무것도 모르지만이 단일 디자인 선택이 문제의 원인이라고 단언 할 수 있습니다.

아마 그렇게!

나는 실제로 코드를 다시 살펴보고 지난번에 내가 뭘 잘못했는지 알아 내고 전역을 해킹하려고 시도했고 node test/someFile.js 테스트 파일을 실행하는 데 필요한 것이 무엇인지 생각했다.

• 글로벌 회피
  
  
  
  • semver 전공에서도 우리는 글로벌을 사용하는 Mocha 사용의 압도적 다수를 깰 수 없습니다. 팀은 모두 하루 일과를 그만두고, 다시는 잠을 자지 않고, 나머지 커리어를 여기에 보내고, 수반되는 상상할 수없는 지원 요청을 처리 할 수있는 인력이 문자 그대로 충분하지 않습니다. 그러므로 이것은 영원히 플래그 뒤에있을 것 입니다.
  
  
  • 현재 BDD 및 TDD 인터페이스는 특수한 경우입니다. 둘 다 require("mocha").it 등으로 내보내집니다 (다른 인터페이스는 없음). (참고 : 다른 인터페이스를 선택할 때 이것이 깨지지 않는 이유는 Mocha가 대부분의 상황에서 다른 인터페이스를 선택하더라도 BDD 인터페이스를 설정하는 버그가 있기 때문일 수 있습니다. # 2207)이 문제에서 벗어나고 싶습니다.
  
  
  • 사용자 정의 (타사) 인터페이스는 내보내기 스키마와 함께 작동 할 수 있어야합니다 ( global 를 하드 코딩하는 대신 내 보낸 컨텍스트 개체를 사용하는 한).
  
  
  • 가능한 모든 인터페이스가 Mocha ( require("mocha") 내보내기)에 기능을 추가 할 수는 없습니다.
  
  
  • BDD 인터페이스가 항상 설정되어있는 버그를 수정하면 Mocha 에서 BDD 및 TDD 인터페이스를 계속 내보내는 것도 까다로울 것입니다. 다른 인터페이스가 선택됩니다.
  
  
  • require("mocha/tddInterface").test 또는 require("mocha/interface/bdd").it 를 수행하지 않는 한 Mocha의 UI를 TDD로 설정하고 BDD 인터페이스를 사용하거나 그 반대로하면 안됩니다 ( "mocha/lib/interfaces/<interface name>" 와 혼동하지 마십시오. 라이브 구현).
  
  
  • semver-major가 될 때까지 이전 버전과의 호환성을 위해 가능한 경우 export-BDD-and-TDD-on-Mocha-on-Mocha-if-possible 동작을 유지할 수 있습니다. 나는 그것을 요청하고 사용하는 사람들이 대부분의 것보다 자신이하는 일에 대해 더 많이 알고 어쨌든 그것에 대해 완전히 만족하지 않는다는 점을 감안할 때 많은 사람들이 그것을 떨어 뜨릴 때 불평 할 것이라고 기대하지 않습니다. 글로벌은 여전히 ​​존재합니다).
  
  
• 노드 능력, 즉 실행 할 수있는 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를 실행해야합니다.
  
  
  • 이를 수행하는 한 가지 방법은 테스트 파일이 비동기 작업을 시작하지 않는 경우 process.on("beforeExit" 에서 Mocha를 실행하는 것입니다.
  
  
  • 이를 수행하는 또 다른 방법은 process.nextTick 또는 setImmediate 또는 setTimeout(..., 0 /* or some small number */) 에서 Mocha를 실행하는 것입니다.
  
  
  • --delay 하고 run() 비동기 적으로 실행하는 테스트는 문제가 될 수 있습니다. 실행시기를 알기위한 것이 아니라 run() 가 있습니다. --delay (아래 참조 또는 require("mocha/nodeable/delayed") ) 여부를 알기 위해서도 아닙니다. run() 는 현재 설계된대로 하나의 테스트 파일에서만 호출되어야합니다. 아마도 디자인은 이미 작업하기 어렵고 어쨌든 모든 테스트 파일에서 run() 가 호출되도록 수정해야합니다.이 경우 "노드 가능"테스트와 함께 사용하는 것이 쉽습니다. 그것을 고쳐라. 그렇지 않으면 ... 어떻게해야할지 모르겠습니다.
  
  
  • node 대신 mocha 를 통해 이러한 테스트 파일을 호출 할 수 있도록하려면 (즉, node 강제로 사용하지 않음) require d는 CLI가 사용 중일 때 감지해야하며 Mocha를 인스턴스화하지 않아야합니다. 이것은 프로그래밍 방식 API가 사용중인시기를 감지하는 것보다 쉬울 것입니다. CLI는 이러한 모듈이 확인할 전역 상태를 설정하거나 이러한 모듈이 CLI가 Node가 실행 한 파일인지 여부를 확인할 수 있습니다.
  
  
  • Node를 통해 실행하거나 mocha.opts 사용할 때 Mocha 플래그 전달을 지원하거나 노드 가능 테스트 파일이 Mocha의 기본값 이외의 동작을 사용하도록 허용하는 모든 것을 지원하려면 CLI 조각을 더 모듈화해야합니다. 행동.
  
  
• 이 두 가지 아이디어의 제약을 결합하여 제안합니다 (그리고 구현할 수 있다고 믿습니다) .
  
  
  
  • 글로벌 회피
  
  
  • 인터페이스에 global 개체를 전달하여 함수를 배치하는 대신 "선택된 인터페이스 개체"를 전달합니다. (추가하기 위해 편집 됨 :이 작업은 lib/mocha.js 및 browser-entry.js 모두에서 수행되어야합니다. 제안의 모든 글로벌 관련 부분이 노드와 브라우저 모두에서 가능하다는 것을 알고 있습니다. )
  
  
  • 그런 다음 선택한 인터페이스 개체의 모든 내용을 global 복사합니다.
  
  
  • localInterface 옵션 (CLI의 --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>") 모카 테스트 파일 후 실행할 모카 설정 인스턴스화 (아마도 사용하여 setTimeout 않는 delay 사용하고, 다시 상기 참조. delay ) 및 require("mocha/interface/<specific interface>") 와 같이 해당 인터페이스에 대해 선택한 인터페이스 개체를 내 보냅니다.
  
  
  • CLI 옵션 또는 mocha.opts 가 지원되는 경우 require("mocha/nodeable") 는 Mocha를 인스턴스화하고 테스트 파일 이후에 실행되도록 Mocha를 설정 (위 참조)하고 CLI와 동일한 인터페이스 설정 단계를 수행하여 require("mocha/interface") 처럼 선택된 인터페이스 객체.
  
  
  • 노드 가능 테스트 파일도 mocha -able이되도록하려면 mocha/nodeable & mocha/nodeable/<specific interface> 가 필요하지 않습니다. mocha/interface 및 mocha/interface/<specific interface>
  
  

생각?

사실, 더 깊이 생각해 보면 mocha <test file> 대신 node <test file> 를 사용하는 것에 대한 다음과 같은 근거에 따라이 티켓을 종료 할 것을 제안합니다.

• 나는 그것이 제공하는 어떤 이점도 알지 못합니다.
  
  
  
  • 한 가지 가능한 아이디어는 mocha.opts 에있는 glob에 관계없이 단일 테스트 파일 만 실행한다는 것입니다. 간단한 해결책 : test 스크립트에 package.json 대신 glob을 넣으십시오. npm test 는 모두를 실행하고 mocha ( node_modules/.bin/mocha , npx mocha )는 지정된 테스트 파일 만 실행합니다. (실행되는 테스트 파일 수에 관계없이 모든 테스트 실행을 위해 실행해야하는 파일 또는 glob은 여전히 mocha.opts 에 있어야합니다.)
  
  
  • 또 다른 가능한 아이디어는 mocha.opts 완전히 우회 할 수 있다는 것입니다. 이제 mocha --opts /dev/null (또는 Windows mocha --opts nul )를 사용하여이 작업을 수행 할 수 있습니다. 어떤 이유로 그렇지 않은 경우 mocha.opts 처리를 건너 뛰도록 CLI 플래그를 구현하는 것이 더 간단합니다.
  
  
• Mocha 외부에서 구현할 수 있습니다. "mocha/nodeable" 대신 Mocha의 프로그래밍 API를 사용하여 동일한 코드를 가상 패키지 "nodeable-mocha" 넣으십시오.
  
  
  
  • 애초에 구현하기 쉽다고 말하는 것이 아니라, 모카 외부에 있기 때문에 구현하기가 더 어려울 수 있다는 것을 알지 못한다는 것입니다.
  
  

외부보다 핵심에서 달성하기 쉬운 중요한 이점을 발견하면 언제든지 다시 열 수 있습니다.

그러나 다음과 같은 이유로 회피 전역 티켓을 다시 열도록 동의합니다.

• 장점은 관련이 없을 것 같지만 ( describe , it 등의 전역을 사용하는 다른 라이브러리가 몇 개입니까?) 원칙적으로 가능합니다 (해당 질문에 대한 답변이 더 클 수 있음). 0보다 적은 수)-이론적으로 글로벌 네임 스페이스에 물건을 버리지 않는 것이 올바른 일입니다.
  
  
  
  • 또한 내 계획은 전역 객체를 하드 코딩하는 대신 내 보낸 "컨텍스트"객체 (현재 Mocha가 항상 전역 객체를 사용함)를 사용하도록 올바르게 작성된 타사 인터페이스로 동일한 동작을 확장합니다. 우리 자신의 인터페이스가 다른 라이브러리를 방해 하지 않는 것처럼 보이지만 다른 인터페이스에 대해서는 보장 할 수 없으므로 올바른 작업을 더 쉽게 수행 할 수 있습니다.
  
  
• 내 계획은 현재 동작에서 많은 관련 엣지 케이스를 정리할 것입니다 (예 : 타사 인터페이스로 확장하지만 BDD 및 TDD 인터페이스의 특수 케이스 대신 Mocha의 일관성).
• Mocha 외부에서 쉽게 구현할 수있는 유일한 방법은 Mocha의 프로그래밍 방식 API를 사용 하고이를 몽키 패치하는 것입니다. 이렇게하면 앞서 언급 한 일부 불일치 및 엣지 케이스도 남게됩니다.

그래서 당신은 Mocha가 mocha 테스트를 실행하는 방법을 제공하지만 global 오염시키지 않는 플래그 뒤에 있다고 제안하는 것입니까?

모카 모카를 만드는 것의 일부와 그 성공의 일부는 물건을 가져 오기 위해 상용구가 필요하지 않다는 것입니다. 글로벌 네임 스페이스를 오염시키는 교리에도 불구하고 개발자 인체 공학을 위해 그렇게해야하는 완전히 타당한 이유가 있습니다.

그래서 당신은 오히려 Mocha가 mocha로 테스트를 실행하는 방법을 제공하지만 글로벌을 오염시키지 않는 플래그 뒤에 있다고 제안하고 있습니까?

예.

모카 모카를 만드는 것의 일부와 그 성공의 일부는 물건을 가져 오기 위해 상용구가 필요하지 않다는 것입니다. 글로벌 네임 스페이스를 오염시키는 교리에도 불구하고 개발자 인체 공학을 위해 그렇게해야하는 완전히 타당한 이유가 있습니다.

일반적으로 동의하지 않는다는 말은 아니지만 옵트 인 기능 으로 일부 개발자가 전역 대신 가져 오기를 원하는 위치를 볼 수 있습니다 (실수로 참조하지 않고 모듈에 지역 변수 context 이름을 지정하기를 원할 수 있습니다. var 을 잊어 버리면 전 세계에 추가 할 수 있습니다. 아마도 이러한 종류의 충돌이 발생할 가능성이 더 높은 타사 인터페이스를 사용하고 싶을 것입니다.) 이제 올바르게 수행하는 방법을 알아 냈습니다. 또한 쉽게보다으로 모카에서 할 추가 기능에 어떤 종류의 (내가 뭔가에 빨려되지 않는 경우 사실, 나는 아마 입증하기 위해 이번 주에 함께 분기에서 초안을 던질거야).

(또한 우리는 이미 일종의 소르 타 시도를 Mocha 개체에 복사되므로 require("mocha").it 할 수 있지만 버전은 이미 있습니다. 솔직히 유지 관리는 이상하고 일관성 이 없으며 버그가 발생하기 쉬우 며 실제로 전역 네임 스페이스를 오염시키는 것을 피하지도 않습니다. 이러한 종류의 기능을 전혀 유지하려는 경우 모호한 버전을 유지하는 것보다 수정 하는 것이 좋습니다.)

이것은 Mocha 테스트에 대해 node <test file> 를 할 수있는 것과는 대조적으로 IMO입니다. 제가 아는 한 어떤 이점도 없으며 Mocha 내부 또는 외부에서 구현하기가 똑같이 어려울 것입니다.

뿡 빵뀨
왜 const {describe, it} = require('mocha') 가 저에게 효과가 없습니까? 방금 정의되지 않았습니다 ...

$ node -v
v8.4.0

@zapphyre 여전히 node 아닌 mocha 프로그램을 통해 테스트 스위트를 실행해야합니다.

node 여러 소스 파일을 실행할 수 없으므로 mocha 고착됩니다. 자체 실행 파일이없는 테스트 실행기 / 프레임 워크를 모릅니다.

더 구체적으로 이슈 제목을 업데이트했습니다.

또 다른 이유 : 다른 JS 런타임 (예 : low.js )을 사용하여 테스트를 실행하고 mocha 를 호출해야 할 때 그렇게 할 수 없습니다.

내 말은, 당신은 이미 브라우저를 위해 그것을하고 있습니다. 이 플랫폼에는 "mocha"를 가져온 다음 mocha.run() 사용하여 전역 mocha 개체에서 테스트를 실행하는 JS 코드가 있습니다.

브라우저에서 I

• mocha를로드하고 전역 mocha 개체를 가져옵니다.
• mocha.setup({ui: 'bdd'});
• SystemJS를 사용하여 모든 테스트 파일로드
• 그런 다음 실행

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

그리고 그게 다야. 테스트 파일을로드하기 위해 SystemJS 대신 require 문을 사용하여 node.js에서 동일한 작업을 시도하면 (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 )을 사용하여 테스트를 실행하고 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 번들과 레거시 번들을 갖는 것이 가능해 보입니다. 새로 추가 된 코드 경로와 번들 만 변경하는 데 많은주의를 기울여야하므로 브라우저와 노드에서 모두 손상되거나 코딩되지 않습니다.

전역 변수와 타이핑을 사용하면 모카 레거시가됩니다.

Btw가 전역없이 @types/mocha 을 생성했습니다 : https://github.com/whitecolor/mocha-types

그들이 (글로벌) 곧 공식적으로 제거되기를 바랍니다.