Last time, I went over more advanced uses of Webdriver as well as putting together a framework of shared methods which can be hooked up to unit tests. For this last post, I’ll be standing up an instance of Selenium Server on Amazon Web Services and refactoring the test framework to point to that instance for testing.
What is Selenium Server?
Selenium Server is basically a hosted service that can accept and run Selenium tests independent of the actual testing client. This allows for shared infrastructure that can be accessed by various clients without repeating the provisioning and setup of WebDriver files and other libraries.
For the provisioning of Selenium Server, I’ve decided to try out Amazon Web Services Elastic Computing service. If you’re curious about AWS and want to take it for a spin, you can sign up for a free trial period that’s currently 1 year! Information on EC2 and a link to sign up for the free trial is available at this link.
Standing up Selenium Server on AWS EC2
So first, I need a host. After signing up for my free trial, provisioning an EC2 virtual machine using Windows Server only took a few minutes.
Then, I was able to copy over the Selenium Server JAR file and the Chrome WebDriver.exe. Both of these can be found at the Selenium downloads page here.
Additionally, since the service is a Java Virtual Machine, I needed to install a Java Runtime Environment located here.
With my host, runtime and libraries in place, it’s time to start the service itself. This involves a simple command line statement. Elements show the location of the Chrome WebDriver on the EC2 host and I’ve also created a log file to keep track of any activity.
java -jar -Dwebdriver.chrome.driver=C:\ChromeWebDriver\chromedriver.exe C:\SeleniumServer\selenium-server-standalone-3.0.1.jar -log “C:\\SeleniumServer\SeleniumLog.txt”
Refactoring the test project
Once the host is available, it’s just a matter of starting the host and telling the framework where it’s located. This requires the download of an additional NuGet package called OpenQA.Selenium.Remote which gives you access to the RemoteWebDriver class. Then I updated my Login and InternalLogin methods to use that as the framework’s IWebDriver object instead of the local one.
With these changes in place, my tests passed with flying colors. While I chose not to run tests in anything but Chrome this time around, adding additional platforms for testing is as easy as adding the drivers to Selenium Server and then updating the DesiredCapabilities argument of the RemoteWebDriver object.
To wrap it all up, I committed my refactor to my SeleniumFramework repo on GitHub. Please feel free to look at the updated version and pass along any feedback you might have.
Again, I hadn’t expected this series to take as long as it did, but it feels good to bring it to a close with some working code to show for it. As always, if you have any questions or comments, please feel free to add them here or address them to john@benedettitech.com.
Thanks for looking in!