Estou vendo exatamente o mesmo problema. Os testes vão passar e o mocha trava. Veja meu Travis CI:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

Eu também notei este mesmo problema em video-dev / hls.js - mocha apenas trava após passar nos testes:
https://travis-ci.org/video-dev/hls.js/builds/282590422

Vocês leram as notas de lançamento? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

Obrigado. tok bad o site mocha não é atualizado com essa alteração significativa. Os cli args não mencionam isso.

Além de fornecer uma solução rápida (use --exit ), concordo que eles deixaram a questão central de encontrar os testes com falha para o usuário. Estou lutando contra isso agora, mas ao atualizar versões principais, leio as notas de versão e não atualizo cegamente

As notas de lançamento sugerem o uso de why-is-node-running exceto que não funciona devido a https://github.com/mafintosh/why-is-node-running/issues/7

Atingido por isso também. Eu entendo o raciocínio por trás da mudança para o padrão , e obrigado por incrementar a versão principal, mas dado que why-is-node-running foi abandonado e quebrado, esta pode não ser a mudança mais amigável.

Olá a todos,

Em primeiro lugar, gostaria de me desculpar pelo caminho de atualização grosseiro neste ponto - nós definitivamente concordamos que o Mocha deve dizer ao usuário o que está mantendo os testes em execução (e então não precisaria nem mesmo manter o processo aberto; poderia apenas ser um motivo para retornar o fracasso depois de concluído), mas ainda não encontrei uma maneira inteiramente satisfatória de fazê-lo. A versão 4 não obteve a quantidade de tempo que desejávamos, pois foi avisado pela falha de nosso CI devido a mudanças no instalador do PhantomJS 1.x (package-lock.json provavelmente teria evitado isso se tivéssemos foi configurado de antemão, mas ainda não conseguimos fazê-lo funcionar ). why-is-node-running foi a única ferramenta que encontramos para ajudar, mas não achamos que possamos integrá-la (entre o requisito de --expose-internals e a falta de uma boa maneira de obter programaticamente sua saída); Descobri que funciona se você seguir algumas etapas:

• execute o Mocha com --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha )
• faça seu primeiro arquivo de teste (por exemplo, listado em mocha.opts ) conter (ou pelo menos começar com) after(require('why-is-node-running'))

... então é melhor do que nada (embora vou ver se posso atualizar as notas de lançamento para descrever isso com mais detalhes), mas se alguém souber uma opção melhor, por favor nos avise!

Também lamento por não encontrar a documentação do site - vamos atualizá-la o mais rápido possível. (Assim que o # 2987 estiver pronto, podemos até torná-lo uma parte automática de nossa versão / script de publicação!)

@ScottFreeCode

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'

Editar:

Isso funciona:

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

Certo, desculpe, não fui claro sobre isso - --expose-internals é uma opção de Nó que pode ser usada executando node --expose-internals ./node_modules/mocha/bin/_mocha vez de ./node_modules/.bin/mocha . Isso também é algo que podemos consertar, já que o Mocha passa certos sinalizadores para o Node e podemos adicionar --expose-internals a esses sinalizadores.

Criado mochajs / mochajs.github.io # 81 e # 3045 para acompanhar a atualização da documentação e sinalizadores de nó do Mocha, respectivamente. Manterá este problema aberto pelo menos até que a documentação seja atualizada.

@ScottFreeCode você pode querer mencionar que --expose-internals só funciona para o nó <= 6. Esperançosamente, as pessoas podem fazer o downgrade para o nó 6 temporariamente para que possam encontrar o temporizador que precisa ser cancelado ou não corrigido , ou os soquetes que precisam ser não ref 'ed. Você também pode indicar às pessoas after e afterEach ganchos para fazerem a limpeza.

(existe um gancho global "depois" que o mocha chama quando todos os testes são concluídos?)

Em qualquer caso, agradeço a ajuda e obrigada pela Mocha!

você pode querer mencionar que --expose-internals só funciona para o nó <= 6.

Você tem certeza? Testei com o Node 8.6.0. Embora não em todos os sistemas operacionais, acho que devo abrir todas as caixas que tenho e verificar três vezes ...

Aqui está uma essência com um guia aproximado para contornar isso por enquanto.

Você tem certeza? Testei com o Node 8.6.0. Embora não em todos os sistemas operacionais, acho que devo abrir todas as caixas que tenho e verificar três vezes ...

Isso "funciona" no sentido de que aciona a saída do módulo, mas não me dá muitas informações, independentemente da versão do Node.js.

Vou adicionar algumas atualizações ao site, mas por favor, veja meus próximos comentários sobre # 3045.

Isso "funciona" no sentido de que aciona a saída do módulo, mas não me dá muitas informações, independentemente da versão do Node.js.

Ele fornece um rastreamento de pilha útil para setTimeout e setImmediate , mas nenhuma informação real para outras coisas como um servidor de escuta (como eu descobri recentemente ao tentar entender como ele está fazendo o que está fazendo). O exemplo "async-dump" na essência tem uma vantagem real em termos de trabalhar para tudo (e não exigir --expose-internals ), embora só possa ser usado em versões mais recentes do Node.

Suponho que meu conselho geral seja "se você está puxando seu cabelo, apenas adicione --exit e relaxe". Então não o use em seu próximo projeto: wink:

... e aqui estão os documentos

Desculpe comentar sobre o PR fechado novamente, mas pode haver uma solução amigável aqui:

Pode-se registrar um aviso sobre a mudança de comportamento após o corredor terminar por 3s ou mais, mas o processo não foi encerrado.
Seria necessário apenas adicionar setTimeout() após o runner terminar e chamar timeout.unref () para garantir que esse tempo limite não impeça a saída do processo. Se o tempo limite for executado, é hora de um aviso 😉

Já pensei nisso, mas tenho medo de que isso cause outros problemas com repórteres ou outras integrações ... Não posso provar que não.

Se você ainda estiver tendo problemas e why-is-node-running não funcionar direito, verifique wtfnode .

Esse pacote funcionou muito melhor para mim.

Eu posso ver como fazer com que os testes existentes parem de sair repentinamente pode ser desconcertante (para dizer o mínimo). Eu vejo uma menção sobre o novo comportamento nas notas de lançamento .

Eu descobri a mudança acidentalmente com novos testes que me forçaram a garantir que chamei redis.quit () em uma função after () e estou definitivamente satisfeito com o novo comportamento, que parece correto e apropriado para mim.

Não precisei usar [esta essência] desta vez, mas como já mencionado por

Devo admitir que não entendo muito bem os problemas nos tickets mencionados que estão por trás dessa nova mudança de comportamento.

AFAICT, tem algo a ver com rejeições não tratadas de Promessas. Mas me perdoe, se você não resolver uma promessa dada a um teste Mocha, então Mocha não terá sucesso nem continuará (se --bail for definido) desse teste, certo? Portanto, deve ser alguma Promessa aninhada mal implementada que não tem um manipulador de rejeição, mas o código que o contém deve estar resolvendo de qualquer maneira.

Se for esse o caso, não vejo como é o trabalho de Mocha detectar esses problemas. E se implementar alguma mágica para detectar esses problemas, o que pode fazer os testes atuais (escritos corretamente) travarem indefinidamente, essa mágica deve ser um comportamento opt-in , não um opt-out - ou seja, --no-exit vez de --exit .

Estou vendo todos os meus testes usando o driver nativo node-mongodb oficial .close() , aparentemente é design. Meus testes estão se comportando corretamente, mas uma dependência não está (ou é? Não sei necessariamente se é um mau comportamento ter soquetes ou descritores de arquivo remanescentes até que um script seja encerrado em outro lugar - você?). Então, o que estou testando aqui? Meu código ou de outra pessoa? Achei que estava testando o meu, mas aparentemente não.

Claro, posso adicionar o sinalizador --exit , mas o próximo não pode, e de qualquer forma, parece errado que eu possa escrever testes perfeitamente bons com código perfeitamente bom sendo testado e ainda ter alguma causa de dependência aleatória meus testes para travar indefinidamente.

Se eu adicionar um process.exit() em um gancho final after() , meus testes não travarão, mas então ele quebrará horrivelmente com --watch (possivelmente outros recursos), não apenas me impedindo de observar as mudanças, mas me ejetando em uma concha sem cursor.

Pode muito bem ser que eu seja o ignorante aqui (certamente há muito que não estou entendendo, e muitas pessoas estiveram envolvidas, então eu tenderia a pensar assim :)), eu sinto que tudo isso coisa não é bem ... certo ...?

Felicidades :)

EDIT: Dado este comportamento, existe alguma maneira de eu verificar dentro de um teste Mocha se ele está sendo executado com --watch para que eu possa ter certeza de não chamar process.exit() e quebrar as coisas?

@DanielSmedegaardBuus TL; DR na solução: coloque --exit no arquivo mocha.opts . (Esta é normalmente a solução para tudo que precisa ser sempre definido quando o Mocha é executado, como uma dica mais geral.) Esclarecimentos mais detalhados sobre o que esta mudança se trata: abaixo.

2640 é sobre rejeições de promessa, não tem a intenção de fazer nada além de torná-las consistentes com exceções síncronas lançadas de código de teste assíncrono não-promessa e ainda não foi implementado .

Trata-se de testes que configuram recursos, ouvintes ou trabalho em curso e não os limpam, independentemente de se usarem promessas na sua implementação e / ou no teste. Por exemplo:

Tenho um teste para uma API baseada em websockets, que inclui abrir e fechar conexões. Esta API estava cheia de erros e não fechava as conexões corretamente, mas passou nos meus testes, pois os testes não tinham realmente uma maneira de garantir que a conexão subjacente foi tratada corretamente. (Se eu tivesse testado estritamente apenas meu próprio código, poderia ter verificado que ele está usando a dependência no que eu pensei erroneamente ser o caminho certo; no entanto, estava testando com o websocket real precisamente para detectar problemas com a correção de uso - testes de integração para complementar os testes de unidade.) Detectei esse erro quando mudei para o comportamento --no-exit (do Mocha 3; agora o padrão no Mocha 4) e descobri que se eu executasse esses testes o Node não fecharia porque a conexão do websocket ainda está escutando.

(É verdade, é possível que o erro esteja em uma dependência, e não em seu próprio código, mas mesmo assim, pode haver valor em saber que, antes de enviar uma determinada versão dessa dependência - como mencionado acima, isso é mais aplicável para testes de integração em primeiro lugar do que para testes de unidade, mas o ideal é que um projeto tenha ambos.)

Isso nem sempre é necessário, é claro - em alguns casos, um recurso dessa natureza pode ser deixado vivo até que o processo seja encerrado ou pode manter o Node vivo, mesmo que nenhuma outra limpeza do recurso realmente importe, ou pode fazer parte de um pool de recursos que reutiliza membros individuais e não precisa limpar o pool como um todo - em tais casos, --exit seria o correto . A razão para a mudança do comportamento padrão foi aumentar a visibilidade de tais problemas: antes, você provavelmente nunca saberia tentar --no-exit e verificar esses tipos de erros, agora você os encontrará por padrão e pode --exit se você determinar que o comportamento é correto (ou pelo menos não vale a pena se preocupar).

É claro que há um problema com a "correção" que simplesmente travar quando isso acontece não é muito informativo . Ainda temos que descobrir se podemos integrar alguma forma de verificar programaticamente as coisas que ainda estão em execução (para que um aviso ou erro adequado possa ser fornecido) que funcione em todas as versões suportadas do Node sem interferir em nada que ainda possa estar limpando ou fechando quando Mocha chega ao fim.

Sinto muito, mas isso foi muito frustrante. Eu só estava tentando descobrir por que o mocha não sai. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit links para why-is-node-running , então agora eu fui, tentei usar aquele módulo, vi uma mensagem enigmática "Erro: Não é possível encontrar o módulo ' internal / linkedlist '... (stack trace) ", e depois de seguir a toca do coelho tentando descobrir por que --expose-internals não funciona, acabo em https://github.com/mochajs/mocha/ Issues / 3045 para encontrar uma suposta solução, mas why-is-node-running me diz que há um identificador conhecido que o mantém aberto e alguns identificadores desconhecidos, mas não lista nada.

Este pode não ser o lugar certo para trazer isso à tona, mas os documentos do mocha não deveriam recomendar soluções que exijam tanta pesquisa no Google e problemas de mergulho para começar a trabalhar . Eu estava tentando tirar coisas e adicioná-las, com um comportamento muito inconsistente. Para o bem de futuros usuários e minha sanidade:

package.json:

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

É o melhor que posso fazer.

@jeffvandyke Eu entendo sua frustração e passei pelos mesmos problemas - mas se você tem alguma afirmação por trás das promessas, pode gostar dessa mudança.

Eu tinha várias especificações que apresentavam comportamento assíncrono irregular. Dependendo da ordem de execução de minhas especificações, erros de rejeição de promessa não detectados seriam registrados no console e, em seguida, perdidos de vista por centenas de outros testes aprovados, ou a instância do nó seria encerrada antes que a rejeição acontecesse.

Depois de remover --exit de meu mocha.opts , as promessas rejeitadas registrariam os erros de maneira confiável e destacariam esses bugs.

Eu sei, muita dor compartilhada :) O comportamento documentado do Mocha na verdade parece correto para mim, mas mesmo que meus 5 testes pareçam simples o suficiente, apenas usando node-fetch para testar uma API, ainda não tenho certeza de por que o mocha não sai , mesmo que todos eles sejam aprovados com sucesso (sim, eles também podem falhar). Eu poderia gastar mais tempo tentando descobrir por que why-is-node-running não está funcionando, mas estou cansado de ficar tagarelando sobre o código de outras pessoas, então acho que vou me dar um tempo por enquanto.

Provavelmente continuarei brincando com ele e, se conseguir algo reproduzível, posso abrir um novo exemplar, mas sem promessas.

recomendaria o novo depurador do inspetor de nó ... ele tem bons rastreamentos assíncronos.

Yay! Acontece que wtfnode é muito melhor para esclarecer isso. Descobri que, ao usar o node-fetch, tenho que chamar result.text() ou .json() ou a conexão permanece aberta. Executar wtfnode ./node_modules/.bin/_mocha e pressionar Ctrl-C revelou as conexões abertas.

Eu acho que teria sido mais fácil se os documentos recomendassem este pacote em vez de why-is-node-running .

Outra sugestão: eu gosto muito da ideia do wtfnode alguma forma para listar os identificadores ativos que mantêm o nó vivo após algum tempo.

Qualquer que seja a coisa certa, acho que é lixo ter que olhar tão longe para descobrir por que o mocha não saía. De qualquer forma, dei minhas sugestões :)

Oi pessoal,
Acho que este recurso ainda pode não estar funcionando corretamente, este é o teste mais básico que eu poderia pensar e o mocha ainda falha ao sair sozinho. --no-exit é uma excelente opção padrão e eu sou totalmente a favor, mas ou não estou entendendo o que estou fazendo de errado ou algo está intrinsecamente errado com o mocha e está impedindo o fechamento até mesmo dos testes mais simples.

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

resumo: --exit funciona, --no-exit nunca fecha nenhum teste.

No meu caso, estou usando um aplicativo Koa e testando com o Mocha 4 + Supertest .

Tive que fechar o servidor com done chamada seguindo as notas de lançamento "Para evitar falsos positivos e encorajar melhores práticas de teste".

Antes:

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

Depois de:

const server = app.listen()

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

Espero que ajude alguém.

Estou fazendo um bootstrapping para mocha antes de cada teste. Basicamente, iniciando um pequeno servidor HTTP no mesmo processo.

Existe um evento que eu posso ligar para desligá-lo depois que o Mocha parar de funcionar? Eu só quero encerrá-lo, mas só naquele momento.

Eu adoro a ideia por trás desse recurso ... é um bom teste para ver se você tem eventos pendentes.

@evert Não funciona fechar o servidor em after ?

Existe um 'depois de tudo' global que ocorre depois que o café é feito? Posso ter perdido isso! Não foi possível encontrar na documentação.

Sim, existe um gancho global after .

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

Obrigado! Eu perdi isso, desculpe: Eu não sabia os termos para usar ctrl-f.

wtfnode realmente não funcionou para mim. Tudo o que pude ver foi que algum PID iniciado por mocha estava pendurado.

Por outro lado, a essência de @boneskull funcionou: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745. Obrigado!

wtfnode precisa ser executado contra _mocha , não mocha .

Obrigado pelo --exit . Ele consertou para mim.

insira este script em package.json:
"scripts": {
"test": "mocha --exit"
}

Tentei vários remédios mencionados neste tópico:

• why-is-node-running não produz saída
• wtfnode produz saída, mas não o suficiente para determinar onde os descritores de arquivo / Sockets / Servers / Timers são criados no código
• erros do método de depuração async_hooks
• adicionar –exit à sinalização de linha cmd mocha resulta na saída

Então siga @ProfJigsaw e use –exit, é isso que estou fazendo. Seria ótimo se houvesse uma melhoria no mocha, pelo menos uma maneira de descobrir onde estão os problemas e como resolvê-los.

É para isso que serve um depurador, IMO. Como você depurará seus próprios scripts se eles nunca tiverem saído?

https://github.com/GoogleChromeLabs/ndb é um projeto legal.

Fora do tópico: adoro este tíquete, apenas pelas informações sobre ferramentas de solução de problemas que ele continua oferecendo! :)

@borisovg Imagine como esse tíquete seria ótimo se realmente fornecesse uma solução! :)
@boneskull Existe algum recurso de depurador "list File descriptors / Sockets / Servers / Timer" que eu não conheço?

@mjgs funcionou para mim - wtfnode funcionou, mas apenas quando o usei com o binário _mocha , não o mocha one:

$ 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 Obrigado pelo seu

Se wtfnode indicar que uma conexão mongo db está aberta, então ela está aberta. Por que você acha que está errado?

@evert , acho que você pode ter interpretado mal o que escrevi

Exemplos mínimos são ótimos para ilustração e na verdade é útil ver uma saída semelhante ao que você está vendo, mas em código real que foi escrito ao longo de muitos anos, essas conexões não são tão fáceis de encontrar. É bom saber que ainda há conexões mongo abertas, mas encontrá-las de fato não é trivial. Acabei encontrando algumas conexões abertas, mas elas eram muito mais profundas no código do que no nível da superfície, onde todas as conexões tinham sido fechadas de forma verificável, wtfnode não ajudou a identificar onde estavam, apenas que existiam, listando o caminho do módulo do mangusto. Ainda tenho alguns para rastrear, com base apenas no número da porta, mas estou esperançoso.

Encontrei esse mesmo problema ao escrever uma função sem servidor que se comunicava com o Firebase. Acontece que seu SDK de administrador mantém um identificador aberto indefinidamente. Por causa dessa mudança (e da sugestão subsequente de usar wtfnode , fui capaz de identificar esse fato e evitar uma tonelada de dor de cabeça (e custos) no futuro.

Na minha opinião, seria muito útil incluir algum tipo de lógica "se ele travar por muito tempo X e não tiver nenhuma saída, lance algum texto para stdout". Não tenho certeza de quão viável isso é ou quanta largura de banda está disponível para produzir tal melhoria, mas acho que pode ajudar a aliviar alguma frustração inicial de "wtf está acontecendo com meu mocha!"

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

Se eu esquecer timers.restore(); o processo fica suspenso para sempre.

Com base na documentação @pgilad enviada aqui, para mim existe uma solução mais limpa. Como diz a documentação :

Para evitar falsos positivos e encorajar melhores práticas de teste, o Mocha não irá mais se matar automaticamente via process.exit () quando achar que deveria ser executado.

Uma solução mais limpa seria criar uma função after global (uma after fora de qualquer função describe ), eu recomendaria em um arquivo separado como exit-mocha.js ou exit-mocha se você quiser. O retorno de chamada enviado para depois que você pode forçar uma saída normal do processo do nó que sairá sem nenhum erro. O arquivo pode ser enviado para mocha cli como se fosse outro arquivo de teste (poderia simular um sinalizador --exit )

exit-mocha.js ou exit-mocha

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

Em seguida, você pode executar testes mocha como:

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

ou

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

É importante que se você estiver usando curingas para o nome dos arquivos de teste como eu fiz com test/**/*.spec.js que o nome do arquivo exit-mocha NÃO corresponda ao padrão curinga, caso contrário, não seja possível para você usá-lo como uma "bandeira"

@ vctr90 Essa é uma ótima solução, embora você tenha um ponto em que deveria

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

Existe alguma chance de um desenvolvedor comentar por que adicionar isso ao Mocha propriamente dito prejudicaria alguém (porque claramente ajudaria muitas pessoas)?

@machineghost Gosto do novo comportamento por 2 motivos:

1. Quase nenhuma outra biblioteca sairá depois de 'fazer seu trabalho'. Por exemplo, fechar um servidor Node TCP não acionará automaticamente uma saída. Dessa forma, é consistente com outras bibliotecas.
2. Se o nó não sair, significa que ainda há eventos esperando para serem resolvidos. Provavelmente é melhor tentar melhorar seu código para que as coisas sejam limpas após cada teste. Também pode sugerir que há vazamentos de memória.

Então, quando me deparo com isso, é um incentivo para tentar limpar meu código para que isso não aconteça.

Sua perspectiva sobre isso pode ser 'não me importo com vazamentos de memória' ou 'não vale a pena consertar em meu aplicativo'. Se você estiver nesta categoria, o mais fácil é fazer mocha.opts e adicionar --exit .

Só me parece que se trata de fazer mais barulho, não de sinal: na maioria significativa dos casos, o aplicativo de ninguém vai melhorar porque o Mocha travou no final.

Se o Mocha vai para o padrão, parece que ele deve terminar quando os testes (e todas as chamadas de after / afterEach ) terminarem. Não fazer isso apenas para dizer às pessoas "ei, seu ambiente de teste artificial é artificial" não beneficia a maioria (ou mesmo uma minoria decente) dos usuários.

Se as pessoas realmente querem depurar conexões não fechadas, então parece que você deve fornecer uma opção para esse caso. Mas, no resto do tempo, realmente beneficia os usuários da biblioteca confundir todos os outros com (o que equivale a dizer) "você está em um ambiente de teste e uma de um bilhão de coisas possíveis está aberta"?

Colocando de outra forma, se você vai dizer a 99% das pessoas que se deparam com este "apenas use --exit " então talvez --exit não deva ser uma opção especial que você precisa fornecer ... talvez o comportamento padrão deva ser servir 99% dos casos de usuário (embora, é claro, ainda dê aos usuários a _opção_ de --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out )?

Quer dizer, se você fizesse essa opção, realisticamente, com que frequência você acha que as pessoas a rejeitariam?

PS: Acabei de descobrir isso: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection. Se você olhar para a segunda resposta, esse comportamento no Mocha fez com que pelo menos um usuário (que não sou eu, e juro que não os conheço: achei isso por sorte depois de fazer minha última postagem) adicionar incorreto código não testado (este "recurso" os fez pensar incorretamente que era necessário chamar knex.destroy() em seu aplicativo).

Versão resumida:

Pessoa simpática: Você provavelmente não precisa chamar explicitamente knex.destroy () - isso está implícito na própria documentação dizendo (grifo meu):

Pessoa simpática: citações documentos

Pessoa confusa: Se eu não chamar knex.destroy (), meu script travará. Então, o que significa que não precisamos chamar explicitamente knex.destroy ()

Pessoa simpática: Ah, você apenas mencionou em outro lugar que isso é para Mocha. Para uso regular de servidor, você não precisa destruir o pool de conexão - para Mocha, você pode querer olhar para um gancho de desmontagem global, veja futurestud.io/tutorials/…

Mas para ser claro, esse usuário tinha um ambiente de trabalho, e como o Mocha (essencialmente) disse a eles que seu código perfeitamente bom estava errado, eles perderam sabe-se lá quanto tempo tentando resolver o bug que criaram destruindo suas conexões. E essa é apenas uma pessoa azarada que fez isso em público, e que por acaso eu vi.

Então, acho que o que estou tentando transmitir é que não se trata apenas do que é filosoficamente correto, nem é apenas que algum ruído está obscurecendo sinais úteis ... esse comportamento está realmente causando danos e fazendo os programadores perderem tempo tentando em moinhos de vento.

Desculpe, eu confundi seu ponto de cansaço com uma pergunta honesta. Lamento responder. Talvez os desenvolvedores possam bloquear este tópico.

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" funcionou para mim. Na verdade, --exit é uma solução alternativa muito boa. Eu uso a versão 5.2.0 em meu projeto.

Existe uma maneira de obter o efeito equivalente de usar o sinalizador --exit ao usar mocha " programaticamente ?"

Não vejo uma opção documentada para exit / noexit, nem uma maneira geral de passar uma string de sinalizador ao usar a API NodeJS.

Seguindo o padrão de outras opções, tentei:

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

mas não foi capaz de obter o efeito desejado.

A inspeção superficial de https://github.com/mochajs/mocha/blob/master/lib/mocha.js parece mostrar que essa opção precisa ser incluída não apenas na documentação, mas também na fonte.

Além de fornecer uma solução rápida (use --exit ), concordo que eles deixaram a questão central de encontrar os testes com falha para o usuário. Estou lutando contra isso agora, mas ao atualizar versões principais, leio as notas de versão e não atualizo cegamente

Como exatamente você o passa? Este é meu script package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } e não está funcionando

Além de fornecer uma solução rápida (use --exit ), concordo que eles deixaram a questão central de encontrar os testes com falha para o usuário. Estou lutando contra isso agora, mas ao atualizar versões principais, leio as notas de versão e não atualizo cegamente

Como exatamente você o passa? Este é meu script package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } e não está funcionando

Tive o mesmo problema e acho que não sou o único. Eu só tive que me mover - sair no final.
Isso não funcionou:
cobertura de istambul ./node_modules/mocha/bin/_mocha --exit - test / .test.jsIsso funcionou comigo:cobertura de istambul ./node_modules/mocha/bin/_mocha - test / .test.js --exit

exit não faz nada ao executar o Mocha programaticamente, fwiw. o processo é encerrado à força pelo wrapper CLI, não pelo Mocha-the-library.