Avoid browser restart (Strategies / Pitfalls)

[phtrivier]

Hi

Launching a folder of nightwatch tests modules typically launches a new browser for each test, making them longer than ideal.
Would that make sense to try and launch all tests using the same browser session ? Are there any "known" strategies to avoid this (ceating the browser in a global setUp / tearDown ?)

Thanks

[beatfactor]

That's not currently possible unfortunately but it would make a valuable addition to have an option to reuse browser session, because in some cases that might not be desired.

[phtrivier]

Ok, I'll give it a try.

[phtrivier]

So i'm in the middle of trying stuff, just to see if that would make sense :

• as far as I understand it, creating the browser session is handled by the Nightwatch module from lib/index.js, in the startSession function
• killing the browser would correspond to the "delete" command place in the selenium action queue in the terminate function of that module
• a new Nightwatch client is created at every test run ; my strategy was to try and pass the sessionId and api.capabilities around between two run, and only terminate the session at the very end of the run (not at every test)
• I managed to pass the sessionId around, but only a single test is run, so maybe selenium stops the browser from another point, I'm still looking

Do you think I'm on the right track ?
Thanks

[phtrivier]

And investigating a bit more, it seems like closing the selenium session is also done by using the 'end' function in a test (as seen in client-commands.js).

I (naively) tried to avoid calling the 'delete' command, but then the test runner never passes to the rest of the test, I'm not exactly sure why :

Original 'end' function :

end : function(callback) {
      var self = this;
       return this.session('delete', function(result) {
         client.sessionId = null;
         if (typeof callback === 'function') {
           callback.call(self, result);
        }
       });
}

My best guess (not sure what the flow of commands is)

end : function (callback) {

     // simulate calling the callback later
     setTimeout(function () {
            // ideally, I would avoid this, but I can keep the sessionId around to pass it to the
            // next client
            client.sessionId = null;
            if (typeof callback === 'function') {
                callback.call(self, {});
            }
      }, 50);

      // for chaining, although in most of my tests, 'end' is the last function called on the api
      return client.api;
}

[ghost]

Maybe running tests parallel would increase the speed... In order to do that we need a parallel test runner...

Currently 1 test is 11 secs by me, and opening a new ff tab is 10 secs of 11...

[ghost]

Hmm according to this: http://sqa.stackexchange.com/questions/1988/selenium-reuse-existing-browser-session-instead-of-opening-new-windows
It is possible to reuse selenium sessions...

[beatfactor]

Yes, it is possible but it needs to be implemented and made configurable
via an options somewhere.

On Tue, Apr 29, 2014 at 6:07 PM, Jánszky László Lajos <
notifications@github.com> wrote:

Hmm according to this:
http://sqa.stackexchange.com/questions/1988/selenium-reuse-existing-browser-session-instead-of-opening-new-windows
It is possible to reuse selenium sessions...

—
Reply to this email directly or view it on GitHubhttps://github.com/beatfactor/nightwatch/issues/117#issuecomment-41696141
.

[dennym]

Any progress on that?

[ryanoasis]

Any updates? Also how did you accomplish

"my strategy was to try and pass the sessionId and api.capabilities around between two run"

if you don't mind my asking?

[tslater]

+1

[phtrivier]

Nope, I don't have any progress to report here (I haven't been working on that for a while.) Sorry.

[mrzmyr]

+1

[Limess]

+1

[limsim]

+1

[andymost]

+1

[ryanoasis]

@beatfactor any updates on when/if this might be coming?

I actually tried to step through the code and try to see how things worked and maybe even attempt to work on this myself but it seemed pretty complex and I don't want to spend time working on something that someone else has plans to do.

[beatfactor]

Yeah, this would be a cool feature. Maybe you can use the new start_session flag to disable the automatic session creation and create your session independently somehow. Feel free to start working on this if you like.

[nyarenbee]

👍

[dreamyguy]

This is the only thing keeping us from adopting Nightwatch on our rig. We think it's awesome but starting a new session for every test file seems overkill and extremely time consuming.

If I only had the kung-fu necessary to get this done... 🙉

Has anyone found a way around this - or managed to run different files through a single Test Suite (which would circumvent the session problem)?

[sknopf]

@dreamyguy if keeping run time low is what you're after you can use the new parallel run feature - might be faster than running your tests serially + reusing browser session

[angelatlarge]

We'd find this a helpful feature as well: we run our tests on CI, and run into port contention between different CI jobs. Having a single selenium session would ensure that once we have a port we can hold on to it.

[finbarmaginn]

+1

[mucsi96]

+1

[sonnenhaft]

+1

[quantuminformation]

+1

[volodya1805]

+1

[aasierra]

+1

[GreenGremlin]

+1

[dreamyguy]

I have come up with a solution that runs all the tests in one browser session. It does not solve the problem but it did the trick for me:

dreamyguy/sidhree-com@67d5a49

The idea is to flatten all tests to one folder, require every file in a single one and run Nightwatch against that file. In this case ./bin/nightwatch --test tests/browser/nightwatch.js.

I'll make those requires more elegant by getting all filenames in that folder and iterating through them, instead of explicitly declaring each. Then I think the setup will be pretty robust.

[DutchKevv]

+1

[beatfactor]

Thanks everyone for input. This has been open for far too long and no resolution is in sight, so it's time to close.