tape: The execution never ends
When I run the test, the execution never ends and what I have to do is in the last test put a process.exit(1)
My package.json looks like this:
"scripts": {
"test": "tape ./test/*.js | tap-spec"
}
there a better way?
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 33 (1 by maintainers)
This can be hepful
Tests are ordinary node processes, so if you have open handles, the process will hang as it ought to.
Calling
process.exit()in your tests is not the best way to solve this problem, since a callback might otherwise double-fire and you wouldn’t know about it. It’s also useful to know if your code is leaking handles. Here’s a way you can set up your tests to avoid this problem:There is a module called
leaked-handlesthat can be used for debugging.Quite the rabbit hole. Had an open handle to mongoDB using mongoose. Just needed to close the connection before the test ended. Of course
t.end()didn’t do anything as substack said.@mattlub @t3hmrman t.plan is also seems to fix
@substack tests are ordinary node.js processes, and therefore a test runner should force-close (with
process.exit(x)) the test process after the final test case?This may be of interest: http://puigcerber.com/2015/11/27/testing-express-apis-with-tape-and-supertest/
Just run into the same thing. Also open connections in a db connection pool.
Now the problem is - I am not sure how to gracefully shut everything down. Given that
supertestis calling theexpressapp directly I have no clue if there is a way to hook into this.The interesting bit - it just works with
mocha.Guy, I can’t explain how, but now after implement more and more tests, I stop with “npm run test --silence” and I run “npm run test” before sends you the code, magically it’s working without the error. I am scared because I don’t undestand what happened hahaha.
well
process.exit()is also bad because the user doesn’t know what exit code to use, the test runner knows the exit code. The user code should not callprocess.exit(), but the test runner should be calling process.exit(). At some point you will have to ignore anything that’s remaining on the event loop. Double callbacks, events that are still attached. Etc.@substack you’re making it harder for the users of your lib, IMO. If all test cases are done, the test is done, finito, there is no point in putting the onus on the users to clean things up, give them a chance to clean up their code in a lifecycle hook, and after that just force exit. Otherwise you will keep having users say “my test process isn’t ending”, etc.
I’ve closed the db connection and it well perfect.
Just encountered this and fixed it by stopping the HTTP server (hapi) and disconnecting from the Postgres database (knex) in my teardown test.
Tape doesn’t do any magic like mocha, if anything keeps the event loop open, it will stay open and you are responsible for closing any connections, etc. I personally think this method helps me understand my application better and avoids issues I’ve had with mocha’s magic getting in the way.
That said, it can be confusing to track down what actually is keeping the event loop open! In the case of express apps, usually its that I have a database connection open (for session storage for example) and need to either
unrefthat in my tests or close it down at the end of my tests.