-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
End Process #49
Comments
That's weird. It should always emit |
It's probably because you still have an event listener open, for example a web server. See #41. |
I see this problem but in a different set up, here's the terminal output:
And the code is simply:
|
Using |
Maybe I'm wrong but I don't see me opening an express server or listening with express. I do require mongoose. But I never close the db connection, because I actually don't know how to do with the async tests. Gulp:
The task scripts just compiles the coffee. Function file:
Specs
There are more specs & functions than that but they all look similar. If I close it after the last describe my code fails. Thus I was hoping to close the connection with ending gulp-jasmine.
|
I'll try to update the docs this weekend with this info, but here's my understanding of what's happening: Gulp and gulp-jasmine run as node processes. A node process exits either when it's explicitely killed or when the event loop has no more listeners. Gulp-jasmine has no understanding of the process in which it's running. It might run as part of a larger, long running process (for example with gulp.watch). It also has no knowledge of the resources your specs use (web server, database connections, file watchers, etc.). It's up to you as a developper to set-up your resources and clean them up once you're done with your tests. The classic way to do this is to use test set-up (beforeEach, beforeAll) and teardown (afterEach, afterAll) to respectively set-up and clean-up your resources. I've included a pattern in #41 that I think is pretty easy to implement and versatile: Instead of having a sequential Hope this helps. |
It sounds like a good solution for handling an express server. But what if I want to end it within gulp-watch? It would be good to automatically close the connections to the database. From my understanding jasmine describes work async, only its can be synced (maybe I'm wrong). Launching mongodb on every before and closing it afterwards could cause duplicate connections. Which throw an error unless the db connections are created with createConnection. |
You have to understand that Jasmine has no knowledge of your code or your requirements. This is not a gulp-jasmine issue. The hooks to let Jasmine know the set-up (opening a connection, starting a server, creating test data, etc.) and tear down required to run your tests are the before* and after* methods. That's hardly unique to Jasmine. I'm leaving this issue open because I want to update the readme with a FAQ since this is a pretty frequent question. As for your specific issue with opening multiple connections, this is easily solvable via a singleton with a counter. Something like this: var connCount = 0;
var conn = ...;
function open() {
if (connCount === 0) conn.open();
connCount++;
return conn;
}
function close() {
connCount--;
if (connCount === 0) conn.close();
} Hope this helps. |
This problem seems to have been around for quite a while in general based on what I've found doing different searches: sindresorhus/gulp-mocha#1 Most people tend to use this approach here: For anything external resource that I hold a connection to, I have a listener for SIGINT. So I used a slightly modified version within my gulpfile:
Basically using signal SIGINT I'm able to close all connections after testing completes, and then exit cleanly. |
I prefer this approach, alluded to above, but not spelled out? For app.js: app.connect = function() {
mongoose.connect('mongodb://127.0.0.1/exampledb');
};
app.disconnect = function() {
mongoose.disconnect();
}; And in an example.spec.js (full gist): /*global describe:false, it:false, expect:false*/
var request = require('request');
var app = require('../app');
var server = require('http').createServer(app);
var baseUrl = 'http://127.0.0.1:3000/example-route';
describe('example-route', function() {
describe('app spinup', function() {
it('should be ok', function(done) {
server.listen(3000);
server.on('listening', function() {
app.connect();
done();
});
});
});
<add your describe/it/expect blocks here>
describe('app spindown', function() {
it('should be ok', function(done) {
app.disconnect();
server.close();
done();
});
});
}); |
I had similar issues where gulp-jasmine ran my tests, but then the process didn't exit. My solution was to use gulp-exit and that ended my task for me. (I'm using gulp-load-plugins, so that is the $). Perhaps not the best solution but it got my task to exit for me. var $ = require('gulp-load-plugins')(); function test(sources) {
return gulp.src(sources)
.pipe($.jasmine({ verbose: true, captureExceptions: true }))
.pipe($.exit());
} |
Fwiw, my solution started failing when i added some middleware that fire up their own redis clients, making app dissconnect/spinDown/close function not stop all of the created listeners. I am switching to gulp-exit, I think. |
I think I just ran into a similar issue myself, where the stream from To me, it looks like the issue is that gulp-jasmine is using the Here is the fix that works great for me 3ee47bb |
TLDR version: to be notified when jasmine completes, use: Longer version: check #71 for more context on this solution. |
@jbblanchet I did read #71, even 'jasmineDone' is not emitted 100% reliably for me. I'd also really prefer using another pipe and not using Regardless of what events to use, I do think it isn't cool to call the flush callback asynchronously without pausing it first. It seems that this breaks the natural stream lifecycle. The stream spec doesn't seem to mention asynchronous callbacks one way or the other. |
Your idea has merit, but I'd like to think about it a bit more. It's not a replacement for the jasmineDone event, because it was implemented for people having no drain downstream, and calling pause should have no effect in that case. Please open a pull request so we can have that discussion there. |
Thats what I came up with, which works for me. The Connection Module
Unit Tests
|
Is there a way to end it after finishing the tests:
It would be useful because then mongoose connections are not opened/ models are not loaded twice. I always have to quit the process in my terminal. I found this but it does not work:
http://stackoverflow.com/questions/27158530/cant-tell-when-jasmine-is-done-running
The text was updated successfully, but these errors were encountered: