Content
Who Is This For?
Introduction
Driver Object
Page
Headers, Footers, and Sidebars
Tests
A Simple Test Script
Who Is This For?
Introduction
Driver Object
Page
Headers, Footers, and Sidebars
Tests
A Simple Test Script
Who Is This For?
While the subject is "Testing", this set of posts is about creating software that tests software. It is assumed that the reader is an experienced programmer with a SOLID background in C#. The material in these posts will not help a manual tester become an automation engineer, but it may help a development team begin to automate well-written manual test cases for which the cost of automation is less than the cost of repetitive manual testing.
Introduction
I want to address using C# and Selenium to create automated user interface tests for web applications. I'm breaking this up into two parts at least. I won't claim to be an expert, but I will claim to have working automation tests on an ASP.NET based website that is live. No one is bound by anything said here. Not even me.
The w3c has a published WebDriver specification. Reading the specification is encouraged, but as the website states, “This specification is intended for implementors[sic] of the WebDriver API. It is not intended as light bed time reading” (https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html). The specification is not the focus of this document. Instead, we are going to focus on an implementation using C# and Selenium WebDriver, available as a nuget package (Figure 1). For this implementation, we will need both Selenium WebDriver and Selenium WebDriver Support Classes.
Figure 1: Selenium Nuget Packages
Driver Object
Figure 2: Driver Object A class should be created for the driver that contains information related to the base URL of the AUT, a method for switching browsers during tests (note. Unless you plan to only test using Firefox, you really will need something like this), and any specific settings you would like to have as default values, for instance, setting an implicit wait that is shorter than the API’s internal default of 10 seconds. Selenium supports a number of different browsers; however, at this time, Chrome and Internet Explorer also require their respective driver servers (these establish a proxy that launches the browser and passes scripted commands from test scripts to the browser).
· ChromeDriver.exe
· IEDriverServer.exe
Both of which can be found on Nuget.
· ChromeDriver.exe
· IEDriverServer.exe
Both of which can be found on Nuget.
Pages
| Pages are an essential part of the automation script. It holds the address of the page that extends from the base URL in the Driver Object as well as locators for each of the elements on the page. Sometimes it is best to encapsulate the services that a page offers (log in, register a new user, create a customer, process an order, and any of a long list of complicated steps that are intended uses of a web page) in the Page which will relate to specific use cases. As you can see at the top of Figure 4, the LoginPage inherits from a BasePage, so let’s take a look at the BasePage first.  Figure 3: BasePage What all of the other Pages inherit are a handful of useful properties and methods that are repeated throughout the test project: pageURL, a GoTo(pageURL) method, and an IsAt bool property. When creating a new Page Object, you first override the pageURL with the URL of the specific page minus the baseURL that you declared in the Driver Object. After that, you can begin creating web elements and services. For the Login page here, I have created a LoginCommand class that accesses the web elements defined in the LoginPage to script the act of logging into the AUT. This is optional, but since most AUTs require a login to do most things, this is probably the safest route to go. It also makes your login test look really simple. |  Figure 4: LoginPage |
Headers, Footers, and Sidebars
Figure 5: Header Object Headers and footers are fairly standard elements in web applications. They give users the impression that while they are navigating through the application, they are still in the same place. Because code should always be DRY, the last thing you want to do is copy these to each page object you create simply because the elements are available on every page. There is an easy way to stay DRY.
Create an object that does not inherit the BasePage class.
This Header Object does not have a pageURL or need the IsAt property because it’s not a page. It contains nearly 20 elements that repeat on almost every single page in the system. Repeating these elements in every page would quickly yield hundreds of lines of repeated code very quickly.
Create an object that does not inherit the BasePage class.
This Header Object does not have a pageURL or need the IsAt property because it’s not a page. It contains nearly 20 elements that repeat on almost every single page in the system. Repeating these elements in every page would quickly yield hundreds of lines of repeated code very quickly.
TestsA test script begins with a BaseTest class. In the base class, we establish our ContextInstance which will help us gather results. Most importantly in the Init() method we initialize our driver. Here, it is hard coded for Internet Explorer; however, if we use data driven testing, this can be made to run in multiple browsers. It's pretty clear to see that we're getting into an area that has a lot of room for different implementations. This is just one.  | Soapbox Automating test cases is an objective that contains a major assumption: test cases exist. Before you can automate anything, a manual test case must have been, at the very least, written. Developing automation is expensive. Doing exploratory development of automation of a system in development is expensive and potentially wasteful. Ideally, UI automation is a process of automating successfully executed test cases, so that manual testers are not wastefully repeating tests for the sole purpose of making sure they still pass. |
A Simple Test Script
This test does not have any Assert statements because I wanted to demonstrate something remarkably simple about automation scripts. You might have a manual script written with a series of steps with expectations next to each step. What's important is that each step should correspond to a line of code in the automation.
| In this case, the manual script would look like:
and so on... |  |
When looking at these two scripts, what stands out is how very similar they are. In the automated test, the expectations are handled by Assert methods just like a unit test.
