Test and Enable Firefox

[arthmis]

Against what version of firefox should this be tested? And how should it be tested?

[saresend]

This is more just to track and explore inclusion of geckodriver. Right now the only thing I have been using is verifying via the chrome webdriver, and this issue was more track how to ergonomically include geckodriver (firefoxes webdriver equivalent), so that users can test against both chrome and firefox seamlessly. My plan was to lock the latest version published here, once development gets underway.

[theredfish]

Hello, I wonder why you want to embed the drivers? We could let the user choose the driver from a specific location :)

[saresend]

For the reason that I think it would ergonomic to leverage projects like this, so that it may be possible to use this without any external dependencies. I think that would be a huge improvement to the current pattern for webdriver testing, which require users to separately configure and run servers and drivers. Hopefully we can bundle the code that actually runs the server and the drivers ( which, ideally, would be cargo install-able), so that the user doesn't have to care about any of that.

[theredfish]

I think I see where you want to go. So, if the user needs a specific webdriver for Chrome, he will update your crate to the specific version? In this case the version will be correctly configured for drivers and the Selenium client. Seems interesting and easier for the users.

Do we speak about a standalone version with all the drivers?

If it's the case, I think we will need to seperate the features of the crate, because some users want to execute their scripts either on remote webdrivers or local webdrivers. By doing this we let the user select what interests him (chrome, firefox, IE, ...) and we offer the possibility to reduce the final binary's size.

[saresend]

It sounds like you're describing something a bit more broad than just how we're providing the geckodriver to users, but I really appreciate the feedback!

In an ideal universe, at least for me, I'd like to provide an api that might look like this:

let webdriver = Webdriver::new(Browser::Chrome, Version::XX);
...

This way users can specify exactly the configurations they want to test, and I'd love to do it in such a way that users don't have to be interested in where exactly these tests are being run (either locally or on a remote webdriver instance, for example). However, if you believe it's valuable to be able to specify the server against which the tests are being run, I'd love to hear the use case! (and possibly might be a reason to split it up into separate "selenium-core" and "selenium-rs" crates, so that users can choose the level of abstraction they'd like to work with!). Finally, since this will likely primarily be a dev-dependency (i.e. release binaries don't need to ship with this), I'm not sure binary size is a huge concern here, though again if there's reasoning I'm missing I'd love to hear it!

[theredfish]

Thank you for your your answers!

Yes I think it's valuable to be able to specify the server. Let me know if I'm missing something in what you said.

Some users could need to run their tests in a parallel way. That's what the Selenium Grid (local or remote) do with multiple nodes :

• It reduces the time for a given execution,
• it allows you to separate the tests from the infrastructure,
• and in my point of view it's easier for CI/CD processes

But, clearly, users need at some point to execute their tests on their machines to check if all is going well before to commit their tests. It's where your solution is great (they don't need to worry about the configuration).

Ok for the dev-dependency. I thought about possible use cases where you need a lightweight binary, but it's more about optimization and it's not a priority I think :).

[saresend]

Okay, so I've looked into it a bit, and I think, as of right now, what we CAN do, is provide a sensible default that makes it painless to get started with this crate. Specifically, I just confirmed that we can likely point and build geckodriver from source (since its written in rust!), as well as the webdriver server itself. This means that, potentially, we can provide firefox testing with no additional work on the userside, simply cargo install and start using it. This would be valuable for people interested in low effort browser automation tasks or scripts, or initial experimental configs for E2E testing.

From there, we can provide an escape hatch where users can point selenium-rs towards a release of either chromedriver, or geckodriver, etc, that we can use to instantiate the actual driver.

Let me know if that sounds good?

[whimboo]

I'm not that involved with the Selenium project but I would suggest to check how other drivers in https://github.com/SeleniumHQ/selenium handle driver setup. It would be wise to follow some over years established patterns, and make it easier for users to use the Rust client.

[saresend]

@whimboo I absolutely agree, however I think it would be exciting to at least explore the option of minimizing external dependencies that users may have to configure, in additional to providing the established API for setting up E2E browser tests.

[theredfish]

Hello,

This would be valuable for people interested in low effort browser automation tasks or scripts, or initial experimental configs for E2E testing

Ok I agree, it's easier for people when they have very simple use cases (like you said for initial experimental configs).

I would like to support the fact that services like BrowserStack, SauceLabs, or some internal companies solutions provide a remote endpoint (the hub from the Selenium Grid or a local server). We'll need to move to this kind of configuration at the end or many people won't be able to use this crate because of its incompatibility with existing solutions.

[saresend]

Yep, I 100% agree with you! If you'd be interested, feel free to open an issue describing specifically what type of interop you'd like to see in this crate 👍