나는 똑같은 문제를보고있다. 테스트가 통과되면 모카가 중단됩니다. 내 Travis CI보기 :
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

또한 video-dev / hls.js에서 동일한 문제를 발견했습니다. 테스트를 통과 한 후 mocha가 중단됩니다.
https://travis-ci.org/video-dev/hls.js/builds/282590422

릴리스 노트를 읽었습니까? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

감사. tok bad mocha 웹 사이트가이 주요 변경 사항으로 업데이트되지 않았습니다. 거기에 cli args는 그것을 언급하지 않습니다.

빠른 수정 ( --exit 사용)을 제공하는 것 외에 결함이있는 테스트를 찾는 핵심 문제를 사용자에게 맡겼다는 데 동의합니다. 나는 지금 나 자신이 어려움을 겪고 있지만 메이저 버전을 업그레이드 할 때 맹목적으로 업그레이드하지 말고 릴리스 노트를 읽으십시오.

릴리스 노트는 https://github.com/mafintosh/why-is-node-running/issues/7 로 인해 작동하지 않는 것을 제외하고 why-is-node-running 사용을 제안합니다.

이것도 맞았습니다. 기본 변경 이유를 이해하고 주 버전을 늘려 주셔서 감사합니다.하지만 why-is-node-running 이 (가) 포기되고 손상 되었기 때문에 가장 사용자 친화적 인 변경이 아닐 수 있습니다.

안녕하세요,

먼저,이 시점에서 대략적인 업그레이드 경로에 대해 사과하고 싶습니다. 우리는 Mocha가 사용자에게 테스트 실행을 유지하는 것이 무엇인지 알려야한다는 데 확실히 동의합니다 (그러면 프로세스를 계속 열어 둘 필요도 없습니다. 완료 후 실패를 반환하는 이유가되지만 아직 완전히 만족스러운 방법을 찾지 못했습니다. 버전 4는 PhantomJS 1.x의 설치 프로그램 (package-lock.json)의 변경으로 인해 CI가 실패함으로써 요청했기 때문에 우리가 원하는 시간을 얻지 못했습니다. 미리 설정했지만 여전히 작동하지 않습니다 ). why-is-node-running 는 도움이되는 도구 중 하나 였지만 통합 할 수는 없다고 생각합니다 ( --expose-internals 의 요구 사항과 프로그래밍 방식으로 출력을 얻을 수있는 좋은 방법 부족 사이). 난 당신이 몇 단계를 수행하는 경우이 작업을 수행 것을 발견했다 :

• --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha )로 Mocha 실행
• (에 나와있는 예를 들어, 첫 번째 테스트 파일 만들기 mocha.opts ) 포함 (또는 적어도 시작) after(require('why-is-node-running'))

... 아무것도 아닌 것보다 낫습니다 (이를 더 자세히 설명하기 위해 릴리스 노트를 업데이트 할 수 있는지 알아 보겠습니다). 더 나은 옵션을 아는 사람이 있으면 알려주십시오!

또한 사이트 문서가 누락되어 죄송합니다. 가능한 한 빨리 업데이트하겠습니다. (# 2987이 완료되면 버전 / 게시 스크립팅의 자동 일부로 만들 수도 있습니다!)

안녕하세요.

borisov<strong i="7">@glossy</strong>:~/test/mocha $ node --version
v6.11.3

borisov<strong i="8">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --version
4.0.0

borisov<strong i="9">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --expose-internals test.spec.js 
  error: unknown option `--expose-internals'

편집하다:

이것은 작동합니다 :

node --expose-internals ./node_modules/.bin/mocha test.spec.js

그래, 미안 나는 그것에 대해 명확하지 않았다 - --expose-internals 실행하여 사용할 수있는 노드 옵션입니다 node --expose-internals ./node_modules/mocha/bin/_mocha 대신 ./node_modules/.bin/mocha . Mocha가 특정 플래그를 Node에 전달하고 해당 플래그에 --expose-internals 를 추가 할 수 있기 때문에이 문제도 해결할 수 있습니다.

mochajs / mochajs.github.io # 81 및 # 3045를 생성하여 문서 및 Mocha의 노드 플래그 업데이트를 각각 추적합니다. 최소한 문서가 업데이트 될 때까지이 문제를 계속 열어 둡니다.

@ScottFreeCode --expose-internals 은 노드 <= 6에서만 작동한다고 언급 할 수 있습니다. 사람들이 일시적으로 노드 6으로 다운 그레이드하여 취소 하거나 참조 해제 해야하는 타이머 또는 필요한 소켓을 찾을 수 있기를 바랍니다. unref 'ed. 사람들에게 after 및 afterEach 후크 를 지정하여 정리를 수행 할 수도 있습니다.

(모든 테스트가 완료되면 mocha가 호출하는 전역 "after"후크가 있습니까?)

어쨌든 도움에 감사 드리며 Mocha에 감사드립니다!

--expose-internals는 노드 <= 6에서만 작동한다고 언급 할 수 있습니다.

확실합니까? Node 8.6.0으로 테스트했습니다. 모든 OS에있는 것은 아니지만, 내가 가지고있는 모든 상자를 실행하고 세 번 확인해야한다고 생각합니다.

당분간 이 문제를 해결하기 위한

확실합니까? Node 8.6.0으로 테스트했습니다. 모든 OS에있는 것은 아니지만, 내가 가지고있는 모든 상자를 실행하고 세 번 확인해야한다고 생각합니다.

이것은 모듈의 출력을 트리거한다는 점에서 "작동"하지만 실제로는 Node.js 버전에 관계없이 많은 정보를 제공하지 않습니다.

사이트에 몇 가지 업데이트를 추가 할 예정이지만 # 3045에 대한 향후 댓글을 참조하십시오.

이것은 모듈의 출력을 트리거한다는 점에서 "작동"하지만 실제로는 Node.js 버전에 관계없이 많은 정보를 제공하지 않습니다.

setTimeout 및 setImmediate 대한 유용한 스택 추적을 제공하지만 리스닝 서버와 같은 다른 작업에 대한 실제 정보는 전혀 제공하지 않습니다 (최근에 그것이 무엇을하는지 이해하려고 시도하는 동안 발견했듯이 하기). 요점의 "async-dump"예제는 Node.js의 최신 버전에서만 사용할 수 있지만 모든 작업 ( --expose-internals 필요 없음) 측면에서 실질적인 이점이 있습니다.

내 일반적인 조언은 "머리를 뽑으려면 --exit 하고 휴식을 취하십시오"라고 생각합니다. 그런 다음 다음 프로젝트에 사용하지 마십시오.

... 여기에 문서가 있습니다.

폐쇄 된 PR에 대해 다시 언급하게되어 죄송합니다. 여기에 사용자 친화적 인 솔루션이있을 수 있습니다.

러너가 3 초 정도 완료 한 후 변경된 동작에 대한 경고를 기록 할 수 있지만 프로세스가 종료되지 않았습니다.
러너가 완료된 후 setTimeout() 를 추가하고 timeout.unref () 를 호출

나는 그것을 고려했지만 그것이 기자 또는 다른 통합에 다른 문제를 일으킬 것이라는 점에 조심 스럽습니다.

여전히 문제가 있고 why-is-node-running 이 제대로 작동하지 않으면 wtfnode를 확인하십시오.

그 패키지는 나를 위해 훨씬 더 잘 작동했습니다.

기존 테스트가 갑자기 종료되는 것이 얼마나 당황 스러울 수 있는지 알 수 있습니다. 릴리스 정보 에 새로운 동작에 대한 언급이

나는 after () 함수에서 redis.quit ()를 호출했는지 확인하는 새로운 테스트를 통해 실수로 변경 사항을 발견했으며 정확하고 적절한 것처럼 보이는 새로운 동작에 확실히 만족합니다.

이번에는 [이 요점]을 사용할 필요가 없었지만 , 이미

나는이 새로운 행동 변화의 배후에있는 참조 된 티켓의 문제를 잘 이해하지 못한다는 것을 인정해야합니다.

AFAICT, 처리되지 않은 Promise 거부와 관련이 있습니다. 하지만 실례합니다. Mocha 테스트에 주어진 Promise를 해결하지 않으면 해당 테스트에서 Mocha가 성공하지도 않고 계속되지도 않습니다 ( --bail 가 설정되어 있으면). 따라서 거부 처리기가없는 잘못 구현 된 중첩 된 Promise 여야하지만 포함하는 코드는 어쨌든 해결되어야합니다.

이 경우 이러한 문제를 감지하는 것이 Mocha의 역할인지 알 수 없습니다. 마법을 구현하는 전류를 만들 수 있습니다 이러한 문제를 감지하는 경우 그리고 (정확하게 작성) 시험은 마법해야한다고 무기한 중지 옵트 인 행동이 아니라 하나의 옵트 아웃 - 즉, --no-exit 보다는 --exit

드라이버가 연결을 풀링하고 .close() 에서 모두 닫지 않기 때문에 공식 node-mongodb-native 드라이버를 사용하여 내 모든 테스트를 살펴보고 있습니다. 내 테스트는 제대로 작동하지만 종속성은 그렇지 않습니다 (또는 그렇지 않습니까? 스크립트가 다른 곳에서 종료 될 때까지 느린 소켓이나 파일 설명자를 갖는 것이 나쁜 행동이라는 사실을 반드시 알 수는 없습니다. 그렇죠?) 그래서 여기서 무엇을 테스트하고 있습니까? 내 코드인가요, 아니면 다른 사람인가요? 나는 내 자신을 테스트하고 있다고 생각했지만 분명히 그렇지 않았습니다.

물론, --exit 플래그를 추가 할 수 있지만 다음 사람은 그렇지 않을 수도 있습니다. 어느 쪽이든 완벽하게 정밀한 코드를 테스트하여 완벽하게 정밀한 테스트를 작성할 수 있고 여전히 임의의 종속성 원인이있는 것은 잘못된 것 같습니다. 내 테스트는 무기한 중단됩니다.

마지막 after() 후크에 process.exit() 을 추가하면 테스트가 중단되지 않지만 --watch (다른 기능 일 수 있음)로 인해 끔찍하게 중단됩니다. 내가 변경 사항을 보지 못하도록 막지 만 커서가없는 셸로 나를 내 보냅니다.

내가 여기에서 단서가없는 사람 일 수 있습니다 (확실히 내가 얻지 못하는 것이 많고 많은 사람들이 관여했기 때문에 그렇게 생각하는 경향이 있습니다 :)). 일이별로 ... 맞지 ...?

건배 :)

편집 :이 동작을 감안할 때, 실행되지 않다면 나를 모카 테스트 내부 확인을 위해 어떤 방법이 --watch 확인 전화하지 내가 할 수 있도록 process.exit() 와 휴식 일이?

@DanielSmedegaardBuus TL; DR on the solution : put --exit in the mocha.opts file . (이것은 일반적으로 Mocha가 실행될 때 항상 설정해야하는 모든 것에 대한 해결책으로,보다 일반적인 팁입니다.)이 변경 사항에 대한 자세한 설명 : 아래.

2640은 약속 거부에 관한 것으로, 아무것도 할 의도가 없지만 약속이없는 비동기 테스트 코드에서 발생하는 동기 예외와 일관성을 유지하며 아직 구현되지 않았습니다 .

이것은 약속이 구현 및 / 또는 테스트에서 사용되는지 여부에 관계없이 리소스, 청취자 또는 진행중인 작업을 설정하고 정리하지 않는 테스트에 관한 것입니다. 예를 들면 :

연결 열기 및 닫기를 포함하는 웹 소켓을 기반으로하는 API에 대한 테스트가 있습니다. 이 API는 버그가 많았고 연결을 올바르게 닫지 않았지만 테스트가 기본 연결이 올바르게 처리되었음을 주장하는 방법이 실제로 없었기 때문에 테스트를 통과했습니다. (내 자신의 코드 만 엄격하게 테스트했다면 내가 잘못 생각한 올바른 방법으로 종속성을 사용하고 있는지 확인할 수있었습니다.하지만 처음부터 사용 정확성 문제를 포착하기 위해 실제 웹 소켓으로 정확하게 테스트했습니다. 단위 테스트를 보완하기 위해 통합 테스트를 수행했습니다.) --no-exit 동작 (Mocha 3, 현재 Mocha 4의 기본값)으로 전환했을 때 오류가 발생했으며 이러한 테스트를 실행하면 Node가 닫히지 않는다는 것을 발견했습니다. websocket 연결이 여전히 수신 중입니다.

(오류가 자신의 코드가 아닌 종속성에있을 가능성이 있지만 그럼에도 불구하고 해당 종속성의 지정된 버전을 제공하기 전에 알면 가치가있을 수 있습니다. 위에서 언급했듯이 이것은 다음과 같습니다. 처음에는 단위 테스트보다 통합 테스트에 더 적합하지만 이상적으로는 프로젝트에 두 가지가 모두 있습니다.)

물론 이것이 항상 필요한 것은 아닙니다. 어떤 경우에는 이러한 특성의 리소스가 프로세스가 종료 될 때까지 살아남도록 의도되거나 리소스의 다른 정리가 실제로 중요하지 않더라도 노드를 살아있게 유지할 수 있습니다. 개별 멤버를 재사용하고 풀 전체를 정리할 필요가없는 리소스 풀의 일부일 수 있습니다.이 경우 --exit 가 정확합니다 . 기본 동작을 변경 한 이유는 이러한 문제의 가시성을 높이기위한 것입니다. 이전에는 --no-exit 를 시도하고 이러한 종류의 오류를 확인하는 방법을 결코 알지 못했을 것입니다. 이제 기본적으로 문제가 발생합니다. 행동이 옳다고 판단되면 (또는 적어도 걱정할 가치가없는) --exit 할 수 있습니다.

물론 이런 일이 발생했을 때 그냥 매달리는 것이 그다지 유익하지 않은 "수정"문제가

죄송 합니다만, 매우 답답했습니다. 모카가 왜 나오지 않는지 알아 내려고 했어요. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit 링크가 why-is-node-running 이므로 이제는 해당 모듈을 사용하려고 시도했지만 "오류 : 모듈을 찾을 수 없습니다."라는 암호 메시지가 표시됩니다. internal / linkedlist '... (stack trace) ", 그리고 --expose-internals가 작동하지 않는 이유를 찾으려고 토끼 구멍을 따라 가면 https://github.com/mochajs/mocha/에 접속합니다. 문제 / 3045 로 가정 된 솔루션을 찾을 수 있지만 why-is-node-running 은 (는) 열린 상태로 유지하는 알려진 핸들이 1 개 있고 알려지지 않은 핸들이 몇 개 있다고 알려 주지만 아무것도 나열하지 않습니다.

이 문제를 제기하기에 적합한 장소가 아닐 수도 있지만, mocha의 문서는 작업을 시작하기 위해 이렇게 많은 인터넷 검색 및 문제 다이빙이 필요한 솔루션을 권장해서는 안됩니다 . 나는 일관되지 않은 행동으로 물건을 꺼내고 추가하려고했습니다. 미래의 사용자와 제 정신을 위해 :

package.json :

"scripts": {
    "test": "mocha --exit"
}

그게 제가 할 수있는 최선입니다.

@jeffvandyke 귀하의 불만을 이해하고 동일한 문제를 겪었지만 약속 뒤에 어떤 주장이 있다면이 변경 사항에 감사 할 것입니다.

비정상적인 비동기 동작을 가진 많은 사양이 있습니다. 내 사양의 실행 순서에 따라 잡히지 않은 약속 거부 오류가 콘솔에 기록 된 다음 통과 한 수백 개의 다른 테스트에 의해 보이지 않게 스크롤되거나 거부가 발생하기 전에 노드 인스턴스가 종료됩니다.

, 제거 후 --exit 에서 내 mocha.opts , 거부 된 약속이 안정적으로 오류를 기록하고, 그 버그를 강조한다.

많은 공유 고통을 알고 있습니다 :) Mocha의 문서화 된 동작은 실제로 나에게 옳은 것처럼 들리지만 5 테스트가 충분히 간단 해 보이지만 node-fetch를 사용하여 API를 테스트 하지만 여전히 왜 mocha가 종료되지 않는지 확실하지 않습니다 . 모두 성공적으로 통과하더라도 (예, 실패 할 수도 있습니다). why-is-node-running 이 작동하지 않는 이유를 알아 내려고 더 많은 시간을 할애 할 수 있지만 다른 사람의 코드에 대해 멍청이에 지쳐서 지금은 휴식을 취할 것입니다.

나는 아마 그것을 계속 가지고 놀 것입니다. 그리고 재현 가능한 것을 얻을 수 있다면 나는 새로운 문제를 열 ​​수도 있지만 약속은 없습니다.

새로운 노드 검사기의 디버거를 권장합니다 ... 좋은 비동기 추적이 있습니다.

예이! wtfnode 가 이것에 대해 빛을 result.text() 또는 .json() 를 호출해야하며 그렇지 않으면 연결이 열린 상태로 유지됩니다. wtfnode ./node_modules/.bin/_mocha 하고 Ctrl-C를 누르면 열린 연결이 표시됩니다.

문서가 why-is-node-running 대신이 패키지를 권장했다면 더 쉬웠을 것 같습니다.

또 다른 제안 : 모카가 종료되지 않으면 어떤 종류의 경고를 받는 @andywer 의 아이디어가 정말 마음에 wtfnode 를 사용하여 일정 시간이 지난 후에도 노드를 유지하는 활성 핸들을 나열 할 수 있다면 좋을 것입니다.

옳은 것이 무엇이든간에 모카가 왜 나오지 않는지 알아 내기 위해 여기까지 봐야하는 것은 쓰레기라고 생각합니다. 어쨌든, 나는 내 제안을 주었다 :)

안녕하세요 여러분,
이 기능이 여전히 제대로 작동하지 않을 수 있다고 생각합니다. 이것은 제가 생각할 수 있는 가장 기본적인 테스트이며 모카는 여전히 자체적으로 종료되지 않습니다. --no-exit 은 (는) 훌륭한 기본 옵션이며 나는 모든 것을 다하고 있지만 내가 뭘 잘못하고 있는지 이해하지 못하거나 모카에 본질적으로 잘못된 것이 있고 대부분의 간단한 테스트도 종료하지 못합니다.

describe('describe', function() { it('it', function(done) { done(); }); });

요약 : --exit 는 작동하지만 --no-exit 는 테스트를 종료 하지 않습니다.

제 경우에는 Koa 응용 프로그램을 사용하고 있으며 Mocha 4 + Supertest로 테스트하고 있습니다.

"오탐을 방지하고 더 나은 테스트 방법을 장려하기 위해"릴리스 노트에 따라 done 호출과 함께 서버를 닫아야했습니다 .

전에:

request(app.listen())
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, done)

후:

const server = app.listen()

request(server)
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, () => {
    server.close()
    done()
  })

소 메노에 도움이되기를 바랍니다.

매 테스트 전에 모카에 대한 부트 스트랩을하고 있습니다. 기본적으로 동일한 프로세스에서 약간의 HTTP 서버를 시작합니다.

Mocha가 실행을 멈춘 후 종료 할 수있는 이벤트가 있습니까? 그냥 종료하고 싶지만 그 때만.

이 기능 뒤에있는 아이디어가 마음에 듭니다. btw .. 매달린 이벤트가 있는지 확인하는 좋은 테스트입니다.

@evert after 에서 서버를 닫는 것이 작동하지 않습니까?

모카가 끝난 후 실행되는 글로벌 '사후'가 있습니까? 나는 그것을 놓쳤을지도 모른다! 문서에서 찾을 수 없습니다.

예, 글로벌 after 후크가 있습니다.

https://mochajs.org/#root -level-hooks

감사합니다! 나는 그것을 놓쳤다, 미안하다 : / ctrl-f에 대한 용어를 몰랐다.

wtfnode 는 나를 위해 실제로 작동하지 않았습니다. 내가 볼 수 있었던 것은 모카로 시작된 일부 PID가 매달려 있다는 것뿐이었습니다.

반면에 @boneskull 요지는 https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745에서 작동했습니다. 감사합니다!

wtfnode 는 mocha 아니라 _mocha 에 대해 실행해야합니다.

--exit 주셔서 감사합니다. 그것은 나를 위해 그것을 고쳤습니다.

package.json에 다음 스크립트를 입력하십시오.
"스크립트": {
"test": "mocha --exit"
}

이 스레드에서 언급 한 다양한 치료법을 시도했습니다.

• 왜 노드 실행이 출력을 생성하지 않습니다
• wtfnode가 출력을 생성하지만 코드에서 파일 설명자 / 소켓 / 서버 / 타이머가 생성되는 위치를 결정하기에 충분하지 않습니다.
• async_hooks 디버그 메서드 오류
• mocha cmd 라인 플래그에 –exit를 추가하면 종료됩니다.

그래서 @ProfJigsaw를 따르고 –exit를 사용하십시오. 그게 제가하는 일입니다. 그래도 모카에 의한 개선이 있다면, 적어도 문제가 어디에 있는지, 어떻게 해결할 수 있는지 알아내는 방법이 있으면 좋을 것입니다.

이것이 바로 디버거의 목적입니다. 자신의 스크립트가 종료되지 않은 경우 어떻게 디버그할까요?

https://github.com/GoogleChromeLabs/ndb 는 멋진 프로젝트입니다.

주제에서 벗어남 :이 티켓이 계속 제공되는 문제 해결 도구에 대한 정보 만 있으면이 티켓이 마음에 듭니다! :)

@borisovg 실제로 해결책을 제공했다면이 티켓이 얼마나
@boneskull 내가 알지 못하는 "list File descriptors / Sockets / Servers / Timer"디버거 기능이 있습니까?

@mjgs 그것은 나를 위해 한 - wtfnode 일을하지만 나는 그것을 사용하는 경우 _mocha 바이너리가 아닌 mocha 하나

$ wtfnode ./node_modules/.bin/_mocha my-shitty-code.spec.js 


  tests
    ✓ some test


  1 passing (5ms)

^C[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Servers:
  - :::8080 (HTTP)
    - Listeners:
      - request: (anonymous) @ /home/borisov/test/my-shitty-code.js:4
- Intervals:
  - (5000 ~ 5 s) (anonymous) @ /home/borisov/test/my-shitty-code.js:8

@borisovg 정말 훌륭한 예를 들어 주셔서 감사합니다. 제 경우에는 wtfnode가 mongo 연결이 열려 있음을 보여 주지만 my-shitty-code.js의 모든 mongo 연결이 닫혔으므로 문제는 다른 곳에서 왔으며 wtfnode는 그것이 어디에 있는지에 대한 충분한 정보를 제공하지 않습니다 에서.

wtfnode가 mongo db 연결이 열려 있음을 나타내면 열린 것입니다. 왜 그것이 틀렸다고 생각합니까?

@evert 나는 당신이 내가 쓴 것을 잘못 해석했을 것이라고 생각합니다.

최소한의 예제는 설명에 적합하며 실제로보고있는 것과 유사한 출력을 보는 것이 유용하지만 수년에 걸쳐 작성된 실제 코드에서는 이러한 연결을 찾기가 쉽지 않습니다. 몽고 연결이 아직 열려 있다는 것을 아는 것이 좋지만 실제로 찾는 것은 사소한 일이 아닙니다. 결국 열린 연결을 발견했지만 모든 연결이 확인 가능하게 닫힌 표면 수준보다 코드에서 훨씬 더 깊었습니다. 포트 번호만으로 추적해야 할 부분이 아직 남아 있지만 희망적입니다.

Firebase와 통신하는 서버리스 함수를 작성하는 바로이 문제에 직면했습니다. 관리자 SDK가 무제한으로 열린 핸들을 유지한다는 것이 밝혀졌습니다. 이 변경 사항 (및 wtfnode 사용에 대한 후속 제안으로 인해 그 사실을 확인하고 길을 잃는 많은 두통 (및 비용)을 절약 할 수있었습니다.

제 생각에는 "만약 X가 오래 걸리고 어떤 출력도 표준 출력에 텍스트를 던지지 않는 경우"로직을 포함하는 것이 매우 도움이 될 것입니다. 그게 얼마나 타당하거나 얼마나 많은 대역폭을 사용하여 이러한 개선을 이룰 수 있는지 잘 모르겠지만 "wtf가 내 모카에서 진행되고 있습니다!"라는 초기 불만을 완화하는 데 도움이 될 것이라고 생각합니다.

var timers = sinon.useFakeTimers({
    now: new Date().getTime(),
    shouldAdvanceTime: true,
});

timers.restore(); 잊어 버리면 프로세스가 영원히 중단됩니다.

@pgilad 가 여기에 보낸 문서를 기반으로 나에게 더 깨끗한 솔루션이 있습니다. 문서에 따르면 다음과 같습니다.

오탐을 피하고 더 나은 테스트 관행을 장려하기 위해 Mocha는 실행이 완료되어야한다고 생각할 때 더 이상 process.exit ()를 통해 자동으로 스스로를 죽이지 않습니다.

청소기 솔루션은 다음 글로벌 생성하는 것입니다 after 기능 (AN after 를 벗어난 describe 기능), 내가 좋아하는 별도의 파일에 추천을 exit-mocha.js 또는 exit-mocha . 다음에 전송되는 콜백은 오류없이 종료 될 정상 노드 프로세스 종료를 강제 할 수 있습니다. 파일은 다른 테스트 파일 인 것처럼 mocha cli로 보낼 수 있습니다 ( --exit 플래그를 시뮬레이션 할 수 있음).

exit-mocha.js 또는 exit-mocha

after('Exit mocha gracefully after finishing all tests execution'. function () {
  // Exit node process
  process.exit();
});

그런 다음 다음과 같은 mocha 테스트를 실행할 수 있습니다.

mocha exit-mocha test/**/*.spec.js

또는

mocha exit-mocha.js test/**/*.spec.js

test/**/*.spec.js 했던 것처럼 테스트 파일 이름에 와일드 카드를 사용하는 경우 exit-mocha 파일의 이름이 와일드 카드 패턴과 일치하지 않는 것이 중요합니다. 당신이 "깃발"로 사용할 수 있습니다

@ vctr90 예제에 쉼표가 있어야하는 마침표가 있지만 훌륭한 솔루션입니다. 또한 모든 것은 다음과 같이 코드 골프를 칠 수 있습니다.

after('Exit mocha gracefully after finishing all tests execution', process.exit);

개발자가 Mocha에 이것을 추가하는 것이 왜 누군가에게 상처를 주는지에 대해 차임 할 수 있습니까? (많은 사람들에게 분명히 도움이 될 것이기 때문입니다)?

@machineghost 나는 두 가지 이유로 새로운 동작을 좋아합니다.

1. '작업 완료'후에는 다른 라이브러리가 거의 종료되지 않습니다. 예를 들어, 노드 TCP 서버를 닫아도 자동으로 종료가 트리거되지는 않습니다. 그런 식으로 다른 라이브러리와 일치합니다.
2. 노드가 종료되지 않으면 해결 대기중인 이벤트가 있음을 의미합니다. 각 테스트 후에 모든 것이 정리되도록 코드를 개선하는 것이 좋습니다. 또한 메모리 누수가 있음을 시사 할 수 있습니다.

그래서 제가이 문제에 부딪혔을 때, 이것이 제 코드를 정리하려고 시도하여 일어나지 않도록하는 인센티브입니다.

이에 대한 귀하의 관점은 '메모리 누수에 대해 신경 쓰지 않습니다'또는 '내 애플리케이션에서 수정할 가치가 없습니다'일 수 있습니다. 이 카테고리에 속한다면 가장 쉬운 방법은 mocha.opts 를 만들고 --exit 입니다.

이것은 신호가 아닌 더 많은 소음을내는 것에 관한 것 같습니다. 대부분의 경우 Mocha가 끝났기 때문에 아무도 앱이 좋아지지 않을 것입니다.

Mocha가 기본으로 설정되면 테스트 (및 모든 after / afterEach 호출)가 완료 될 때 기본적으로 종료되는 것 같습니다. 사람들에게 "당신의 인공 테스트 환경이 인위적입니다"라고 말하지 않는 것은 대다수 (또는 상당수) 사용자에게 이익이되지 않습니다.

사람들이 정말 닫히지 않은 연결을 디버깅 할 경우 다음은 당신이에 대한 옵션을 제공하는 경우이어야한다 보인다. 그러나 나머지 모든 시간 동안 다른 모든 사람들을 "당신은 테스트 환경에 있고 10 억 개의 가능한 것 중 하나가 열려 있습니다"로 혼동하는 것이 도서관 사용자에게 정말로 유익합니까?

이로 실행이있는 사람들의 99 %가 말하려고하는 경우, 달리 말하면 "단지 사용을 --exit "어쩌면 --exit 당신이이 특별한 옵션 안 제공 ... 아마도 기본 동작은 사용자 사례의 99 %를 제공하는 것이어야합니까 (물론 사용자에게 --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out 의 _option_을 제공함)?

내 말은, 만약 당신이 그 옵션을 만들었다면, 현실적으로 사람들이 그것을 얼마나 자주 통과 할 것이라고 생각합니까?

추신 : 방금 https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection을 발견했습니다. 두 번째 답변을 보면 Mocha 의이 행동으로 인해 적어도 한 명의 사용자 (저가 아님을 맹세합니다. 저는 마지막 게시물을 작성한 후 운이 좋게 발견했습니다)가 잘못 추가되었습니다. 테스트가 아닌 코드 (이 "기능"로 인해 앱에서 knex.destroy() 를 호출해야한다고 잘못 생각했습니다).

요약 버전 :

좋은 사람 : 일반적으로 knex.destroy ()를 명시 적으로 호출 할 필요는 없습니다. 이것은 문서 자체에서 다음과 같이 암시합니다.

좋은 사람 : 인용 문서

혼란스러운 사람 : knex.destroy ()를 호출하지 않으면 스크립트가 중단됩니다. 그렇다면 명시 적으로 knex.destroy ()를 호출 할 필요가 없다는 것은 무엇을 의미합니까?

좋은 사람 : 아, 당신은 이것이 모카를위한 것이라고 다른 곳에서만 언급했습니다. 일반적인 서버 사용의 경우 연결 풀을 해체 할 필요가 없습니다. Mocha의 경우 글로벌 해체 후크를 살펴볼 수 있습니다. futurestud.io/tutorials/…

하지만 분명히이 사용자는 작업 환경을 가지고 있었고, Mocha (본질적으로)가 완벽하게 좋은 코드가 잘못되었다고 말했기 때문에 연결을 끊음으로써 생성 한 버그를 해결하는 데 얼마나 많은 시간을 할애했는지 알 수 없었습니다. 그리고 그것은 단지이 하나의 불운 공공 장소에서 그것을 할 수 있었던 사람, 누가 내가 볼 수 있었던입니다.

그래서, 제가 전달하고자하는 것은, 이것은 단지 철학적으로 옳은 것에 관한 것이 아니라 일부 소음이 유용한 신호를 가리는 것도 아닙니다.이 행동은 실제로 해를 끼치고 프로그래머가 기울이는 시간을 낭비하게 만듭니다. 풍차에서.

죄송합니다. 피곤한 점을 정직한 질문으로 착각했습니다. 대답을 후회합니다. 개발자가이 스레드를 잠글 수 있습니다.

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" 가) 저에게 효과적이었습니다. 실제로 --exit 는 아주 좋은 해결 방법입니다. 내 프로젝트에서 버전 5.2.0 을 사용합니다.

mocha "를 프로그래밍 방식으로 사용할 때 --exit 플래그를 사용하는 것과 동등한 효과를 얻을 수있는 방법이 있습니까?"

exit / noexit에 대한 문서화 된 옵션이나 NodeJS API를 사용하는 동안 플래그 문자열을 전달하는 일반적인 방법이 표시되지 않습니다.

다른 옵션의 패턴에 따라 시도했습니다.

const mocha = new Mocha({
    exit: true,
});

그러나 원하는 효과를 얻을 수 없었습니다.

https://github.com/mochajs/mocha/blob/master/lib/mocha.js의 커서 검사는이 옵션이 문서뿐만 아니라 소스에도 추가되어야 함을 보여줍니다.

빠른 수정 ( --exit 사용)을 제공하는 것 외에 결함이있는 테스트를 찾는 핵심 문제를 사용자에게 맡겼다는 데 동의합니다. 나는 지금 나 자신이 어려움을 겪고 있지만 메이저 버전을 업그레이드 할 때 맹목적으로 업그레이드하지 말고 릴리스 노트를 읽으십시오.

정확히 어떻게 통과합니까? 이것은 내 package.json 스크립트입니다.

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } 작동하지 않습니다.

빠른 수정 ( --exit 사용)을 제공하는 것 외에 결함이있는 테스트를 찾는 핵심 문제를 사용자에게 맡겼다는 데 동의합니다. 나는 지금 나 자신이 어려움을 겪고 있지만 메이저 버전을 업그레이드 할 때 맹목적으로 업그레이드하지 말고 릴리스 노트를 읽으십시오.

정확히 어떻게 통과합니까? 이것은 내 package.json 스크립트입니다.

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } 작동하지 않습니다.

같은 문제가 있었고 나는 유일한 문제가 아니라고 생각합니다. 나는 단지 움직여야했다-끝에서 나가기.
이것은 작동하지 않았습니다.
이스탄불 커버 ./node_modules/mocha/bin/_mocha --exit-test / .test.js이것은 나를 일했습니다.이스탄불 커버 ./node_modules/mocha/bin/_mocha-test / .test.js --exit

exit 는 Mocha를 프로그래밍 방식으로 실행할 때 아무것도하지 않습니다. fwiw. 프로세스는 Mocha-the-library가 아닌 CLI 래퍼에 의해 강제 종료됩니다.