-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Http Server not closing after tests #178
Comments
in test:
and in app:
|
@martypdx Mocha 4.0 changed the default behavior. So, if you decide to upgrade to Mocha 4.x you'll need to add the
|
Thanks for the issue @martypdx and thanks for the responses @liesislukas and @cklanac. I think all of the work-arounds seem valid; just depends on which one you'd be happiest with in your test suite. Would anyone like to file a PR improving our documentation around this? Listing the alternative ideas? I'd be happy to merge such a PR! |
Thanks for responses, makes sense. I think one thing that might help from an API perspective is to expose the server as a prop on the request when using the listening function overload, or at least offer close method. To effectively deal with this issue, you have to run your own Generally though, having access to the server seems logical: const chai = require('chai');
const chaiHttp = require('chai-http');
chai.use(chaiHttp);
const app = require('../../lib/app');
const request = chai.request(app);
after(() => request.server.close()); |
Yeah, actually this makes a lot of sense. I worry though - what of the ergonomics when using a non-express app, what will |
@martypdx if you want to share the agent, use |
@martypdx @keithamus we could have something like |
I see little point in making it a callback - as then we'd simply offer no assurance it got called, and no way to verify at runtime if it was doable. I suppose having I'd welcome a PR which adds |
Do you mean a I did notice that the Whether Happy to help with PR
Cookies? Aren't those just used by ads, invasive trackers, and tedious oauth calls? 😉 |
Sorry, yes, I meant strings. |
@martypdx 'workaround' seems to me to be not a workaround but the proper way. The change to mocha exposed a flaw in this lib's api, although it seems convenient, having request start a listening server by itself and then relying on mocha to murder it when its no longer wanted is a bad plan. I think just changing the documentation, and maybe deprecating passing a requestListener function has my vote. Somehow exposing the internally started http.Server, otherwise returning a null if an an address had been passed to request smells funny to me. With those changes, if I understand the code correctly, the only reason the http.Server is being passed in is to build the address string that would have been passed in. So the docs would read something like: chai.request() takes a URL
If you are running a express server, as a convenience, you can pass in the server itself and the URL is obtained automatically from server.address().address and server.address().port ( hence doesn't work with koa or hapi )
|
This automatically closes server connections after making a request; so that test runners (like mocha 4) aren't left hanging after the test execution. If someone really needs to keep the server open, `.keepOpen()` can be used. Fixes #178 BREAKING CHANGE: This change closes servers down after every request. If you want to use the server for reasons at the same time as your test suite or for some other reason you dont want the server to automatically be shut-down, then you'll need to change any `chai.request` callsites to also use the `keepOpen` comand, like so: ```js chai.request(server).keepOpen() ```
This automatically closes server connections after making a request; so that test runners (like mocha 4) aren't left hanging after the test execution. If someone really needs to keep the server open, `.keepOpen()` can be used. Fixes #178 BREAKING CHANGE: This change closes servers down after every request. If you want to use the server for reasons at the same time as your test suite or for some other reason you dont want the server to automatically be shut-down, then you'll need to change any `chai.request` callsites to also use the `keepOpen` comand, like so: ```js chai.request(server).keepOpen() ```
Fixes chaijs/chai-http#178, caused by mochajs/mocha#3044.
* chore(package): update dependencies * docs(readme): add Greenkeeper badge * Update lockfile * Close server after tests Fixes chaijs/chai-http#178, caused by mochajs/mocha#3044.
When using `chai-http`, `mocha` doesn't seem to exit but instead waits. There seems to be some workarounds (chaijs/chai-http#178), but adding this argument is the easiest for now until more code is written.
For anyone having an issue using CircleCi where the build won't complete this solves it |
Hey I've been using chai-http for testing for quite some time and I'm 95% sure that it would correctly allow mocha to exist after the tests are run. Now though, it just causes mocha to hang after the tests. If I pass in a server (instead of a listening function) and explicitly close, it terminates correctly.
Below are steps for workaround I had to use to get it to work:
The text was updated successfully, but these errors were encountered: