-
Notifications
You must be signed in to change notification settings - Fork 87
allow testing in Selenium locally using --selenium #271
base: master
Are you sure you want to change the base?
Conversation
|
By analyzing the blame information on this pull request, we identified @rase-, @JamesKyburz and @bevacqua to be potential reviewers |
39fb718 to
e7f33bb
Compare
|
Hm, that's weird. This was working a moment ago, but now all my tests are stalling because apparently the or |
|
Not getting the done event could be linked to your previous issue about ipad/iphone stalling tests no? |
|
I don't think so; I was talking about locally, not using SauceLabs. Gonna try to keep digging when I get a chance, though. |
|
Nevermind; it was a programming error on my part. This now works in both Chrome and Firefox! Getting it to work in Travis' Chrome is a TODO, but in principle this should work right now in Travis using |
|
Also I wasn't quite sure how to test this? I guess I should add a new test to the |
e7f33bb to
fda2ddf
Compare
|
The current travis build can fail only because of saucelabs credentials not being available. You can check the full test suite locally by using |
|
Adding a test for this feature could just be maybe trying to run a new test fixture through real selenium on travis firefox? If this passes locally for you I will run the branch on travis myself. Or maybe just create user and keys for zuul and put them public because this is annoying |
|
|
||
| See the [quickstart](https://github.com/defunctzombie/zuul/wiki/quickstart) page on the wiki for more details. | ||
|
|
||
| ### Automated browser tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe local browser tests? Because it's always automated right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "automated local"? I wanted to highlight that this isn't designed for debugging, and to distinguish it from --local.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just "Running through phantomJS" "Running through local Selenium server"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really bike shedding here, this is a great PR :)
fda2ddf to
cb0c85a
Compare
|
OK, I've added tests. Unfortunately I think Travis will still be red because I'm not a member of this org. However it ought to work if an org member runs the tests. I also changed the default from Chrome to Firefox. A few reasons:
|
|
Note that we may also need to add this to the .travis.yml. Haven't confirmed yet: before_script:
- "export DISPLAY=:99.0"
- "sh -e /etc/init.d/xvfb start" |
|
Argh I am unable to load tests locally, I get Uncaught Error: connection refused: localtunnel.me:42801 (check your firewall settings). WHereas it's working on travis strnagely (master). Will push a branch here. |
|
I am also unable to run the tests on travis strangely it is stuck at IE11 |
|
Same issue (local tunnel) on master local |
|
Anything you need to help get this merged? Sounds like failures are unrelated to my PR unless I'm misunderstanding. |
|
I tried multiple time to run the tests on this PR without any luck. Basically at some point the test does not exits? You should be able to run the full test suite by creating an opensauce account on saucelabs (or reuse existing keys you have) then: DEBUG=zuul*,localtunnel* SAUCE_USERNAME=username SAUCE_ACCESS_KEY=key npm testCurrent master branch exits without issues, but your branch does not. Weird. |
|
Hm, my hunch is that it's because we also need to add this to .travis.yml: before_script:
- "export DISPLAY=:99.0"
- "sh -e /etc/init.d/xvfb start"Should I add that to this PR? |
Yes, does it also means I should do this when running locally? How did you run tests locally? Ultimately it would be good to be able to run tests "locally" easily because that's currently doable with the line I gave you. When running your branch I did see firefox running and closing btw |
|
@vvo Which version of Firefox are you using? Pretty sure when I tested this I was on 43 or later. I'll try to find time to test this PR again; I think this would be a great feature for Zuul! |
|
I tested with latest stable firefox |
|
OK, I can reproduce. OS X ElCap with FF 44. Firefox closes but for some reason the process never exits. I tried to debug why it hangs, but can't figure it out. 😕 Feel free to close this PR if nobody has time to debug it. I took a shot at it, but I couldn't figure out what was causing the process to stay open. |
|
I had the same issue (process stay open), will try with latest selenium and see how it goes |
|
Now localtunnel is too frequently failing sadly for me to go further |
|
This PR is almost good, the code works but we are not able to make the tests passes. We could merge it without tests and wait for issues to come (alon with potential resolvers). WDYT? |
|
I would prefer to have tests passing. I'm just very sorry I didn't have time to push this further. :( Your call. |
One feature I've really wanted from Zuul is to be able to test in Travis without using SauceLabs.
For instance, Travis comes pre-installed with Firefox, and it also supposedly has Chromium installed in there. It would be nice to be able to test locally against their version of Firefox, without having to use SauceLabs.
This PR adds a new flag,
--selenium, that will (by default) launch Chrome and run the Zuul tests in Chrome. Additionally, if you specify--browser-nameand/or--browser-version, those options will be passed to Selenium to determine which version to test.I could have made Firefox the default, but it seemed like 6 of one, half a dozen of the other to me. Also I'm mostly opening up this PR to get feedback.