app.stop() throwing errors with Jasmine when all windows are manually closed
See original GitHub issueI am trying to test to make sure the window is closed properly because I implement some logic in the onbeforeunload event and I want to ensure that it is not failing.
If the window closes correctly, I receive the following error: - Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
. The error is happening because app.stop() does not seem to be returning its promise when all windows are closed so done() was never called. If I change the line that says app.stop().then(done)
to done()
then the test passes but the app never quits in the background and the test suite will not return until the user kills it. Also if I change app.quitTimeout to 2000 ms then the test passes but the app doesn’t quit.
I am using OS X El Capitan, jasmine 2.3.2, and spectron 3.3.0
it('should close the window', (done) => {
app.start().then(() => {
app.browserWindow.close().then(()=> {
app.client.getWindowCount().then((count) => {
expect(count).toEqual(0);
app.stop().then(done);
});
});
});
});
Just for sanity, my test case checking if a window is created passes and quits the app as expected without error.
it('should open a new window', (done) => {
app.start().then(() =>{
app.client.getWindowCount().then((count) => {
expect(count).toEqual(2); //webviews are also counted here
app.stop().then(done);
});
});
});
Any thoughts/suggestions?
I apologize in advance if this is very simple and going right over my head.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:2
- Comments:13
Top GitHub Comments
Closes the running windowless application as expected, thanks! However my test suite is still hanging after all tests are run, even with no running instances of electron. I believe this specific problem may be related to jasmine-node however as it seems others have had similar problems.
I have the same issue on Windows but without Jasmine.
app.stop()
does not close the window. Would be great if this can be fixed. At the moment I am using the workaround proposed by @danielwestendorf. Thanks for that!