I could see using xpath and css and name to verify that the element is exactly the element we intend to instantiate when development does not add an id to the element, but id is a unique identifier in the DOM and development should be encouraged to use id unless it is impossible. 

The benefit of @FindBys is that we can be very specific about the element we are finding.

The drawback is that if we have an id, but the location of the element changes on the page and we specified both id and xpath, we will no longer get the element.

The real downside to this is that we can’t check the functionality of the page if the layout changed or a css selector changed which may not affect the usability of the application, but does cause your tests to error.  If we relied only on id, then the tests would continue to work regardless of the look and feel.  If look and feel have enough business value to create automated tests against them, then maybe try creating an entirely separate project to test that and give the Galen Framework a try.

As a .NET developer, I really didn't have that much trouble getting started with Selenium.  I had Nuget to grab everything, and I depended heavily on the tools built into Visual Studio.  But none of us are guaranteed to be working in the same environment forever.  Things changed.  I went looking for new challenges.  I found them rather immediately, but now I can tell everyone who reads this about them.  Let me help you save some time.

You need to find the latest Selenium Client and WebDriver Bindings.
Then you need a browser driver.  I'll use ChromeDriver for this, but you should be able to use whichever browser you want (or all of them if you want to try cross browser testing, but that's an advanced topic for a totally different time). 

1. Create a new Java Project.

2. Add External Libraries

• Right-click on the project in Package Explorer
• Select Properties => Java Build Path => Libraries => Add External JARsd
• This is where you browse for the Selenium Client and WebDriver bindings and add the client jar file as well as all the jar files in the lib folder.

3. You need to put the browser driver you downloaded somewhere your IDE can get to it or properly set the PATH variable for the browser driver of your choice.

4. Now you need a base test class for your tests and a base page class for your page objects.

Once you have these things in place, you can start to create your page objects and tests.  

Content
Who Is This For?
Introduction
Driver Object
Page
Headers, Footers, and Sidebars
Tests
A Simple Test Script

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.

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.

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.

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.

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.

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.