E2e tests not working (at least on Windows) after running generator

[tomwayson]

Like #11 , after a fresh install and successfully running npm start

I then run:

npm test

Selenium vomits out into the console, but it's all cleared before I can tell if it started successfully or not. Then I see the following:

tests/intern
Tunnel: Starting

Total: Pending
Passed: 0  Failed: 0  Skipped: 0

It just kind of hangs and flickers. Same happens when running grunt e2e directly.

I can successfully run selenium from the command line w/ the same args:

java -jar tests/lib/selenium-server-standalone-2.46.0.jar -Dwebdriver.chrome.driver=node
_modules/chromedriver/bin/chromedriver
07:29:41.937 INFO - Launching a standalone Selenium Server
Setting system property webdriver.chrome.driver to node_modules/chromedriver/bin/chromedriver
07:29:42.002 INFO - Java: Oracle Corporation 23.7-b01
07:29:42.002 INFO - OS: Windows 7 6.1 x86
07:29:42.002 INFO - v2.46.0, with Core v2.46.0. Built from revision 87c69e2
07:29:42.049 INFO - Driver class not found: com.opera.core.systems.OperaDriver
07:29:42.049 INFO - Driver provider com.opera.core.systems.OperaDriver is not registered
07:29:42.127 INFO - RemoteWebDriver instances should connect to: http://127.0.0.1:4444/wd/hub
07:29:42.127 INFO - Selenium Server is up and running

Then I get the following when trying to run grunt intern from another terminal window I see the following in the selenium window:

22:28:54.216 ERROR - org.apache.commons.exec.ExecuteException: Execution failed (Exit value: -559038737. Caused by java.io.IOException: Cannot run program "C:\code\test\yo-ags-app-master\node_modules\chromedriver\bin\chromedriver" (in directory "."): CreateProcess error=193, %1 is not a valid Win32 application)

Looks like selenium is having trouble launching chromedriver.

I can get the tests to run using chromedriver w/o selenium by running the following in a git-bash window and then running grunt intern in another window:

node_modules/chromedriver/bin/chromedriver --port=4444 --url-base=wd/hub

However, to run in normal windows command window I have to run:

"node_modules\.bin\chromedriver" --port=4444 --url-base=wd/hub

At this point, I've lost too many hours of my life f&*^ing around w/ selenium and browser drivers to try and debug Intern problems. I don't see how anyone can possibly use it. Maybe it works great on a Mac.

[tomwayson]

Sorry, I got frustrated towards the end of last night's debugging session.

In summary, doesn't look like there's anything wrong w/ the intern config or tests. Looks like it's just a matter of how selenium is calling chromedriver (maybe just on Windows).

A few things to try:

• Do the e2e tests work on Mac?
• Do the e2e tests work if you add chromedriver to your path and omit the cmd line param pointing out the location?

Another idea is to scrap selenium and just use the chromedriver. As I said above, I was able to run that from the command line and have the tests successfully run. I didn't look into calling it from grunt.

I'm not going to look into this any further. I gave up on the Intern a long time ago. Maybe @gbochenek or @gavinr can look into the config they use on their Intern projects to see how it's done there.

[odoe]

e2e isn't working on Mac either. I don't know if it's a selenium/chromedriver version issue or what. This used to work out of the box. I'll test on Linux.

[odoe]

I had been meaning to update to this module https://github.com/zs-zs/grunt-selenium-standalone

Tried it and same issue. I'll keep testing

[odoe]

So as-is, if I run the command-line selenium test first, then shut it down, I can run grunt e2e, and it works. This is on Linux.

Local Selenium testing seems finicky at best here. If I can fix it, I will, but we should add a note that Saucelabs is really the preferred way of cross-browser testing, because you can only test what you have installed as it is.

[tomwayson]

"finicky" is an understatement for the experience on Windows :stuck_out_tongue_winking_eye:

I've got a local fix that takes selenium out of the picture and just uses chromedriver and works reliably on windows (and I suspect should have no prob on other platforms). It seems reasonable to me to advise people to only test locally against chrome and to use something like SauceLabs via CI if they need to test in other browsers (which is really the only sane way to do so). Seems like SitePen agrees.

I've also excluded deps like esri, dojo, etc from code coverage reporting and that speeds up test runs significantly.

PR to come later this weekend unless you don't agree that it's sufficient to test locally only against chrome. I'll also include a note in the README w/ the above into. Let me know if that sounds good to you.

[odoe]

Sounds awesome! Go for it.

On Sat, Mar 26, 2016, 8:45 AM Tom Wayson notifications@github.com wrote:

"finicky" is an understatement for the experience on Windows [image: :stuck_out_tongue_winking_eye:]

I've got a local fix that takes selenium out of the picture and just uses chromedriver and works reliably on windows (and I suspect should have no prob on other platforms). It seems reasonable to me to advise people to only test locally against chrome and to use something like SauceLabs via CI if they need to test in other browsers (which is really the only sane way to do so). Seems like SitePen agrees https://theintern.github.io/intern/#local-selenium.

I've also excluded deps like esri, dojo, etc from code coverage reporting and that speeds up test runs significantly.

PR to come later this weekend unless you don't agree that it's sufficient to test locally only against chrome. I'll also include a note in the README w/ the above into. Let me know if that sounds good to you.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/odoe/generator-arcgis-js-app/issues/12#issuecomment-201864929