[NOTE: This is a guest post from Telerik’s own Phil Japikse, one of Telerik’s Senior Developer Evangelists."]
User Interface testing isn’t just for quality engineers. It’s vital for developers to own part of this process as well. The days of development silos are long gone (or at least should be!) The process of throwing bits “down the line” is fraught with inefficiencies.
Developers are already adopting unit testing in record numbers, and this has led to a phenomenal increase in code quality. Why should it stop there? Developers need to also take ownership of the user interface code just like the line of business code that they develop.
Is this to say that we don’t need quality engineers? Absolutely not! What I am saying is that developers should ensure that the basic elements of the user interface are correct, and the process for testing these basic elements need to be automated just like standard unit tests are automated.
Telerik’s Test Studio has an extremely powerful record/replay capability. Did you know that Test Studio’s underlying Testing Framework also provides the ability for developers to write UI tests with most of the common unit testing frameworks? In this post, I am going to show you the basics of writing functional tests with MbUnit and Gallio, leveraging the power of the Telerik Testing Framework.
For this example, I am going to use a standard ASP.NET MVC application. The test is simple:
There is a little bit of housework that needs to be done before this test can be developed. This isn’t much different than what you need to do to create a test project for standard unit tests, there are just a few more steps. You need to create a unit test project, select a unit test framework, add the Telerik Testing Framework references, and finally create a class that derives from the BaseTest abstract class provided by the Telerik Testing Framework.
The Telerik Testing Framework works with any .NET unit testing frameworks. I typically use MBUnit/Gallio in conjunction with the Telerik Testing Framework to leverage the Gallio report writer, which I will demonstrate in a future post.
There are two references that need to added to the test project. Right click on the test project, select “Add Reference…”, click “Browse…”, then navigate to “C:\Program Files (x86)\Telerik\Test Studio\Bin\” and select:
Listing 1 shows the default implementation that is needed to use the Telerik Testing Framework in unit tests. To write tests leveraging the Telerik Testing Framework, this is the minimum code that needs to be implemented in the base class that TestFixtures will inherit.
public class WebAiiUITestsBase : BaseTest
/// Initialization for each test.
public void MyTestInitialize()
// Initializes WebAii manager to be used by the test case.
// If a WebAii configuration section exists, settings will be
// loaded from it. Otherwise, will create a default settings
// object with system defaults.
// Pass in 'true' to recycle the browser between test methods
// If you need to override any other settings coming from the
// config section or you don't have a config section, you can
// comment the 'Initialize' line above and instead use the
// This will get a new Settings object. If a configuration
// section exists, then settings from that section will be
Settings settings = GetSettings();
// Override the settings you want. For example:
settings.DefaultBrowser = BrowserType.FireFox;
// Now call Initialize again with your updated settings object
// Place any additional initialization here
/// Clean up after each test.
public void MyTestCleanUp()
// Place any additional cleanup here
// Shuts down WebAii manager and closes all browsers currently running
// after each test. This call is ignored if recycleBrowser is set
/// Called after all tests in this class are executed.
public void FixtureCleanup()
// This will shut down all browsers if
// recycleBrowser is turned on. Else
// will do nothing.
Listing 1 – The base class for Test Fixtures
Creating your first Unit Test
Start by creating a standard Test Fixture, with two distinctive changes:
· The fixtures must be set to Single Threaded (due to limitations in how browsers and the Windows User Interface work)
· The fixtures must derive from our base class (created above)
Once those two changes are completed, unit tests can be added in the standard manner, as shown in Listing 2.
public class LoginUITests : WebAiiUITestsBase
public void Should_Fail_Log_In_With_Bad_Username_Or_Password()
The first step in testing a web application is launching a browser. The Telerik Testing Framework supports a number of browsers (assuming they are installed on the system running the unit test), as shown in Figure 1.
Figure 1 – The Browser choices
Once the browser is launched through the manager, the browser instance gets assigned to the ActiveBrowser property of the BaseTest class. The ActiveBrowser exposes quite a few properties and methods, and I am only going to scratch the surface in this post.
The first thing I need to do is to navigate to the website I am testing. In my particular scenario, the url is “http://localhost:3916/”. Since all of my tests will start with this address, I add a property to my base class, as in Listing 3.
protected string _coreUrl = "http://localhost:3916/";
Listing 3 – Home Page for the site under test
My test now looks like Listing 4, which is how each of my tests begin.
public void Should_Fail_Log_In_With_Bad_Username_Or_Password()
Listing 4 – Creating the Browser and Navigating to the Start Page
You might be wondering why I don’t move those two lines into a TestSetup method. While the full answer is too long and off topic for this post, I feel that TestSetup methods obfuscate the tests and become a problem leading to fragile tests.
The Telerik Testing Framework supplies an extremely robust mechanism for finding elements on a page. The methods are generic, which enables Test Studio to return strongly typed elements. For example, the first item that I need to find is the HTML Anchor that has the inner text “Log On”. If the element is found, the Find process will return an HTMLAnchor class that exposes (among other elements) a Click() method. The next step is to verify that the logon page is loaded, and I use the ActiveBrowser.Url to assert that condition. This is shown in Listing 5.
Assert.AreEqual(_coreUrl + "Account/LogOn",
Listing 5 – Clicking an HTMLAnchor and validating the result
The next steps are to find the text box and the password text boxes, and enter the user name and password as defined in the spec. For these, we will FindByName instead of FindByContent, since we know the form values are named. With the strong typing of the Find methods, we can then set the Text property for each of the controls. The last step is to submit the entered values by finding the HTMLInputSubmit button. This code is shown in Listing 6.
Find.ByName<HtmlInputText>("Username").Text = "admin";
Find.ByName<HtmlInputPassword>("Password").Text = "foo";
Listing 7 – Entering and submitting values
The final step in our spec is to verify that the web page shows the correct error message, and we again call on the ActiveBrowser object to validate that the page contains the text that we are looking for, as shown in Listing 7.
Assert.IsTrue(ActiveBrowser.ContainsText("The user name or password provided is incorrect"));
Listing 7 – Asserting the Text in the webpage
The completed test is shown in Listing 8
Find.ByContent<HtmlAnchor>("Log On", FindContentType.InnerText).Click();
Assert.AreEqual(_coreUrl + "Account/LogOn", ActiveBrowser.Url);
Listing 8 – The completed test
This post merely scratched the surface of what the Telerik Testing Framework provides to developers. Testing really needs to become a way of life for all aspects of software development, not just the quality engineers. Remember, if you don’t test it, your users will!
Telerik’s Testing Framework is freely available for download from the product’s home page. You can immediately start writing functional tests for your HTML, Silverlight, or WPF applications! Want someone on call to help you with issues? Get a year of top-notch support from Telerik’s amazing support crew for only $299. (More details at the product’s home page.)
Why not go give the Telerik Testing Framework a try?
Philip Japikse is an international speaker, a Microsoft MVP, INETA Community Champion, MCSD, CSM/ CSP, and a passionate member of the developer community, Phil has been working with .Net since the first betas, developing software for over 20 years, and heavily involved in the agile community since 2005. Phil works as a Senior Developer Evangelist for Telerik's RadControls for Windows 8 as well as the Just family of products (JustCode, JustMock, JustTrace, and JustDecompile) and co-hosts the Hallway Conversations podcast (www.hallwayconversations.com). Phil is also the Lead Director for the Cincinnati .Net User’s Group (http://www.cinnug.org). You can follow Phil on twitter via www.twitter.com/skimedic read his Telerik blog at http://blogs.telerik.com/skimedic and his personal blog at www.skimedic.com/blog.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.