In Selenium IDE you could simply use getSelectedLabel | locator and that was your currently selected item in the drop down list. Its a bit more of a roundabout way with WedDriver as you can see from the method I have written below:
[code]
using OpenQA.Selenium;
using OpenQA.Selenium.Support.PageObjects;

// …

public string getSelectedLabel(ddlDropListID)
{
string selected;
SelectElement selectOption = new SelectElement(ddlDropListID);
selected = selectOption.SelectedOption.Text;
return selected;
}
[/code]

View Details

In WebDriver there is no direct replacement of the Selenium IDE command selectFrame, however there is a fairly straightforward approximation by using the driver.SwitchTo() method. This method allows you to change the focus to different windows, alerts and frames, but we will be focussing on frames in this post. Below are examples on how to switch to a frame by using its ID, its parent frame, or the top level.

To select the frame by specifying its ID, replace [code] selectFrame | frmFrameID | [/code]
With:
[code]
IWebElement frmDashboard = null;
frmDashboard = driver.FindElement(By.Id(“frmDashboard”));
driver.SwitchTo().Frame(frmDashboard);
[/code]

To select the top level frame, replace [code] selectFrame | relative=top | [/code] with the following line
[code] driver.SwitchTo().DefaultContent();[/code]

And finally to select a frame by the current frame’s parent frame, replace [code]selectFrame | relative=up | [/code] with the following line
[code] driver.SwitchTo().ParentFrame();[/code]

View Details

Page Objects are a way to encapsulate the technical details of a web page and the services it provides so that the developer of a test does not need to delve into the structure of the webpage. Essentially the Page Object acts as an interface between the web page and the testing of that page. The Page Object defines all the elements and actions provided by the web page and the test case uses these to execute the test(s). By clearly delineating the test code from the page objects, you will be able to use the same page objects in a variety of tests cases and achieve code re-use. Another major positive to this approach is that if the application being tested changes then only the Page Object definition needs to be changed in one place and all of the existing test should still work once that change had been made.

I will provide tangible examples later but I used C# to define the Page Object and its properties and methods. The test cases use these objects and methods with NUnit to provide Assertions. This is an important point; the tests, and not the Page Object, should be responsible for making assertions about the state of a page. The Page Object defines the properties and methods you need for creating a test and the test itself uses those properties and methods to make Assertions, allowing us to determine if a test has passed or failed.

The Code

I think the best way to learn a new concept is by getting your hands dirty and trying it out. In this example I will show how to use the Page Object Model to define a Login Page.
Below I will create a page object for Login and I will define some properties (username, password and login button) and a method to login. As the LoginUser() method will take us to a new page, it will return a HomePage object.

[code]
using OpenQA.Selenium;
using OpenQA.Selenium.Support.PageObjects;
using NUnit.Framework;

namespace PageObjectModel
{
public class LoginPage
{
private IWebDriver driver;

[FindsBy(How = How.Id, Using = “tbxUsername”)]
private IWebElement tbxUsername;

[FindsBy(How = How.Id, Using = “tbxPassword”)]
private IWebElement tbxPassword;

[FindsBy(How = How.Id, Using = “btnLogin”)]
private IWebElement btnLogin;

public LoginPage(IWebDriver driver)
{
this.driver = driver;
PageFactory.InitElements(driver, this);
}

public HomePage UserLogin(string user, string pass)
{
tbxUsername.SendKeys(user);
tbxPassword.SendKeys(pass);
btnLogin.Click();

return new HomePage(driver);
}
}
}
[/code]

So that’s a very simple Page Object setup, I’ll go through it in more details once we have the code for the test case that uses it:

View Details

In WebDriver you can call javascript functions programatically without having to click on a link with javascript code as the href attribute. This functionality uses the IJavaScriptExecutor interface. This allows you to execute javascript commands on your browser from your Selenium Webdriver test. Here is a short example to get the current URL:
[code]
IWebDriver driver;
// … … …

IJavaScriptExecutor js = driver as IJavaScriptExecutor;
string url = (string)js.ExecuteScript(“return document.url”);
[/code]

Or you can use functions or methods to be called also

[code]
IWebDriver driver;
// … … …

IJavaScriptExecutor js = driver as IJavaScriptExecutor;
js.ExecuteScript(“OpenModalWindow(‘testfile.html’)”);
[/code]

I have created a fairly simple to use C# method to perform a MouseOver operation, all you need to do is to specify the web element to MouseOver.

Add the following using statement first:
[code]using OpenQA.Selenium.Interactions;[/code]

Then create the following method:
[code]
public static void MouseOver(IWebElement theElement)
{
Actions builder = new Actions(driver);
builder.MoveToElement(theElement).Build().Perform();
Thread.Sleep(1500);
}
[/code]

Its fairly easy to use and I have a sample of how to call it below:
[code]
IWebElement theMenuLink = driver.FindElement(By.Id(“menu”));
MouseOver(theMenuLink);
[/code]

There are a number of different ChromeDriver options (and for the other browsers too) that allow us to control how the browser starts up. In this example we see how Chrome is started when no options are selected:
ChromeDriver

Using the following options we can specify that Chrome start without the warning message and that it starts maximised.
[code]
var chromeOptions = new ChromeOptions();
chromeOptions.AddArguments(“–test-type”,”–start-maximized”);
driver = new ChromeDriver(chromeOptions);
[/code]

How to use an NUnit Configuaration file to pass values to a test at runtime?

  1. Create your XML Configuration file using the format below. Add your Key,Value pairs in appSettings section
  2. Use the correct file name for your config file
  3. Add a reference to System.Configuration and add a corresponding using statement
  4. Use the ConfigurationManager object to access your parameters in your test code

(1) Basic Config File is in this format:
[code]
<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
<startup>
<supportedRuntime version=”v4.0″ sku=”.NETFramework,Version=v4.5″ />
</startup>
<appSettings>
<add key=”TestURL” value=”http://www.example.com/”/>
<add key=”Browser” value=”Firefox”/>
</appSettings>
</configuration>
[/code]
(2) Config File Naming Scheme
Your config file has to be in the same folder as the test dll, and it must be the same name with .config suffixed. For example if you test dll is called MySeleniumTest.dll your config file must be called MySeleniumTest.dll.config, and it must be located in the same folder.

(3) Add a Reference to System.Configuration
In your Visual Studio project, add a reference to System.Configuration, as well as a corresponding using statement:
[code]
using System.Configuration;
[/code]
(4) Use ConfigurationManager object
Here is an example of how you can access your config parameters in your NUnit tests:
[code]
testURL = ConfigurationManager.AppSettings[“TestURL”];
browser = ConfigurationManager.AppSettings[“Browser”];
[/code]

View Details

This post will outline the basic structure of how to setup your C# NUnit test. First of all here is the code of the basic empty C# NUnit test file. I’ll explain all of the different parts below.
[code]
namespace MyWebDriverTest
{
[TestFixture]
public class Class1
{
[Test]
public void TestCase01()
{

}
}
}
[/code]

The two attributes [TestFixture] and [Test] are used by the NUnit Framework to indicate that there are tests to be executed. The [TestFixture] attributes is used by NUnit to indicate that the class contains test code. This class must be public and must also have a default constructor. The [Test] attribute indicates that the method is a test method. Test methods have to return a void and also must have no parameters.

Everything else is standard C# code for defining a class and a method.

This is the basic setup for a C# NUnit WebDriver test, and we will use this a s starting point for more in-depth tests in later posts.