In this blog series I am going to work through creating automated UI tests for an ASP.NET app using C# and Selenium. I was motivated to write this because I struggled to find relevant and accurate information online, which is I think is just a result of how long Selenium has been around and improved over time. My goal is to highlight and explain the key pieces required starting with Selenium WebDriver in 2017.
What is WebDriver? (WebDriver vs. RemoteControl)
WebDriver is the tool we are going to use to automate interacting with the UI. It is pretty powerful and can be used for any browser automation task, not just UI testing. It relies on each browser’s native support for automation and requires a driver for each browser. The official WebDriver documentation is actually pretty good, even if it seems like it might be out of date (ignore the disclaimer at the top).
Which nugets to use?
This was a point of confusion for me initially that nowhere explained. There are multiple official nuget packages, what do they all do and which ones do I need?
You can ignore the Selenium.RC nuget and also Selenium.WebDriverBackedSelenium as it provides WebDriver functionality but with the RC API. It exists to transition code using RC to WebDriver, without it to be rewritten to work with the WebDriver API.
To go along with this blog series I have created a SeleniumExamples repo on GitHub which will have code that I refer to. At the time of this post there is a very basic example of using WebDriver with the driver for Chrome to go to the Google homepage in the
Open_Google_Chrome method of the _1_Bare_Minimum_Web_Driver_Example class.
xUnit is my personal preference to run tests and any other test framework, e.g. NUnit, would also work. If you are using xunit, don’t forget the Visual Studio runner.
Since I decided to use Chrome, I needed to add the Chrome driver. There is a 3rd party nuget package that adds it, but I decided to download it and add it into a Dependencies directory in the project. I wanted to do this a bit out of habit (at One Model we follow this pattern for other required executables) and to make sure I could control where the driver gets added so that I can make them all live in the same folder (when I add others).
I also decided to set the project to copy the driver into the output (bin) directory on compile. I did this in case I want to deploy the test project elsewhere in the future to run tests, and this way all that is required is copying the entire bin directory. This might end up being unnecessary, but did not hurt to do now.
To create an instance of ChromeDriver requires that chromedriver.exe is somewhere in the computer’s PATH, or that you pass the full directory of where it is located as an argument. I prefer that the repo can be cloned and run without any system configuration, so I took the approach of providing the directory as an argument.
From there the code to open the browser and navigate to Chrome is pretty straight forward.
That’s it for this post. In the next post I add an example web application for testing on and have it start automatically before the UI tests run.