Code modified to make browser as a configurable property.

[smonami]

Two changes:
1.) huxley/cmdline.py modified to accommodate browser as a setting parameter so that we can define which browser to use for tests.
2.) README.md's Technical FAQ section modified to include description for above mentioned new setting parameter.

[petehunt]

I originally had a different command-line interface that exposed all of these options, but I felt like it got unwieldy. This can be accomplished by launching a different Selenium server and pointing Huxley at the correct URL -- do you think that's sufficient or can you see a reason why we would need this instead?

[davewasmer]

+1 for this - I'm relatively new to selenium, and the less time I have to spend learning the difference between Selenium RC 1, Selenium Service, ChromeDriver, and a dozen other concepts, the better.

Right now I'm trying to get my tests to run with Chrome, and can't seem to get huxley to launch using it.

[smonami]

@petehunt, I was thinking this way we will not need multiple instances of selenium servers. This will give flexibility to test in different browsers just by adding/modifying one setting!
Also there will be just one place to put all our configuration/parameters so it will be easy to manage test cases.

[YoDK]

+1

[petehunt]

So I've been thinking about this a little more.

The problem with putting the browser in the Huxleyfile is that you may want to reuse the same recording on multiple platforms (imagine testing every old IE at once!). However today that's not possible since each test case has a single set of screenshots regardless of the platform.

Additionally we use Huxley in continuous integration, where we prefer to use the selenium server URL, so if we add this feature we need to support selenium URLs too.

I'm thinking that we take a more aggressive approach to this. What if there were HuxleyEnvironment file sitting in the root of your project that listed all of your test environments. Something like:

dev=browser:firefox
dev-chrome=browser:chrome
jenkins-ie=webdriver:http://seleniumURI
jenkins-opera=webdriver:http://seleniumURI
jenkins-firefox=webdriver:http://seleniumURI

Then you could specify the environment(s) you want to run in with the huxley command. A different set of screenshots could be kept for each platform.

If no HuxleyEnvironment was found we'd have a default one which uses the current behavior of hitting a localhost selenium server.

Would this solve your problem? Would this be too complicated for people to understand?

[smonami]

@petehunt this will solve the browser selection problem. And proper documentation/example can reduce the complexity of implementation details!

[petehunt]

I will be working on this soon!

[YoDK]

👍

[jukkatupamaki]

Any progress with this one? In the 0.4 version, I cannot set Huxley to use Chrome instead of Firefox in Windows environment.

Looks like that in the Python code it defaults to using Firefox even though there are other options listed. Passing the parameter -Dwebdriver.chrome.driver="path to chromedriver.exe" to Selenium Server does not have any effect.

[petehunt]

Beginning work on this this week. Part of this is going to involve adapting Huxley to work in a team environment a bit better.

[petehunt]

As part of this I landed parallel runs into master; still working on the rest of these features.

[plasticine]

Hey guys,

Not sure if it is off-topic for this discussion, but I’ve been thinking about a use-case that I think might be worth considering.

I was wondering if it might be worth considering dividing the modes of operation a bit more, and being able to define a “record browser” (something with a GUI, say, Firefox via selenium) which is responsible for recording/re-recording user interactions and producing the record.json. It would then be possible to farm out the actual testing and screenshot production to a set of “test browsers”, whether they be something headless like PhantomJS, or a whole range of browsers and mobile devices via Selenium Grid (or whatever).

This seems like a better division of responsibilities to me — a constant browser with a GUI that produces a record.json that can be picked up by anything that speaks web-driver and tested.

What do you think? Hope that makes sense :)

[petehunt]

Have you looked at the HUXLEY_WEBDRIVER_REMOTE and HUXLEY_WEBDRIVER_LOCAL variables?

[fionawhim]

I'd really like to be able to specify Chrome from the command line. Can I help at all with the coding to make it happen?

[kalupa]

Is there any chance this will be merged in? I'd rather use a pip installation than a github one to get this feature.

Yes, you can point it at different servers. But the great part of selenium is that you can tell the grid which capabilities you want to test against. This would be an ideal use case if you want to use a SaaS selenium grid like BrowserStack, etc.

[smonami]

@petehunt, Another thought, can we provide both the features? One, attached to this issue and the other bigger change what you are working on?