Why Developers Should Help With User Interface Tests

by Jim Holmes on September 02, 2014

Automated User Interface (UI) testing has a deserved reputation for being a morass of low-value, high-cost pain. Developers are already over-burdened trying to get the work in front of them completed and into the delivery pipeline. Why should they look to take on additional work in helping create functional tests at the User Interface level?

Ship Better Value

Every developer should care about delivering better value to their customers, regardless whether their customers are internal or external. Better value means the delivered software is in alignment with what the customer’s true needs are (which is often not exactly what they asked for). Better value means software that is performant enough in the customer’s environment to keep the customer’s users happy. Better value means few, if any, bugs escaped out to the customer requiring support and patches.

Important sounding stuff, no? And these are just a few of the reasons why developers ought to take interest and have a stake in UI-level testing.

Test the Scary Things

UI testing is time consuming, both for the initial creation and ongoing maintenance. With that in mind, teams that are already busy building software can’t afford to disrupt their current flow for low-value, senseless automation.

Instead, teams should focus on the most critical, high-value features. What’s keeping your stakeholders awake at night? Generally it’s around two broad areas:

  • Can we make money?
  • Are we going to get sued?

Flippant prose aside, these really are two solid areas to focus on. Are the features that impact revenue (or your business-critical work) stable and working? Are you properly securing highly sensitive data? Of course you’d use those as a starting base, but the point is to talk with your stakeholders and understand the most critical areas of the system.

Take a shopping cart system as an example. Simple testing of the checkout system’s UI isn’t enough. You’d want to ensure that any integrations with third-party payment providers such as PayPal, Discover and Visa are rock-solid. If integrations with those providers aren’t working properly, then your company is likely losing revenue and incurring extra customer service costs due to failed transactions.

That’s the place where you begin building your UI scripts, not automating checks around look and feel or icon placement.

How Much to Test?

UI tests should be viewed as an extension and companion to other types of testing you are (or should be) doing already. A well-tested system will have a mix of different test types. Lisa Crispin and Janet Gregory use a “testing pyramid” as an example in their book Agile Testing.

Unit tests–those with no dependencies–should make up the majority of automated tests in a system because they’re fast to write and run, and maintenance costs are lowest. The middle of the pyramid is integration tests–those crossing service boundaries–since they’re slower to run and costlier to write and maintain. UI tests with their high costs should be at the top of the pyramid: a few carefully chosen tests that exercise high-value flows.

Let’s take some examples from computing wages as part of a payroll system. Here’s how things might break out:

  • Unit Tests: Test the method/algorithm calculating wages. Validate proper wage is computed for workers based on inputs of hours worked, worker’s hourly rate, and whether or not the worker earns overtime.
  • Integration Tests: Test interaction to other systems/layers. Check the security system integration to ensure only permitted users can execute payroll activities.
  • UI Tests: Check the flow of generating payroll. Validate an authorized user can click the right buttons and see that the payroll was properly executed.

These last paragraphs centered on automated tests. You should be having some form of manual testing going on as well! I won’t get into the debates around the various schools of testing. Suffice it to say, you should have skilled testers exploring your system alongside your automated tests.

Does It Really Work Like You Thought?

Interactions across boundaries are a frequent source of bugs. It’s not surprising because invoking those calls, managing their lifecycle, and handling errors/exceptions is a relatively difficult task. Integration tests help drive great design and solid API behavior across those boundaries, but it’s not enough if you stop there.

Testing a workflow from the UI all the way down to the database is the final step in ensuring your systems’ interactions are behaving properly. Is your UI updating properly after a CRUD action? An integration or unit test wouldn’t have caught that. Is caching interfering with updating rows on your grid? Whoops! Discovering that is the domain of a functional UI test too.

Automation as Acceptance Tests

Automation frameworks can also serve as acceptance criteria for new work, regardless of whether you’re using some form of specification toolset (See Gojko Adzik’s wonderful book Specification By Example) or just tying your automation to acceptance criteria in Telerik TeamPulse.

Cucumber is one popular tool that lets teams create text specifications over the top of drivers like the Telerik Testing Framework or WebDriver. Cucumber lets you write things like:

Given I am logged on as a payroll administrator When I edit an employee’s pay rate Then I am able to update their salary 

Below is a similar scenario using an automated test in Telerik Test Studio tied to acceptance criteria in TeamPulse.


Acceptance criteria TeamPulse and Test Studio

Using automation in this fashion helps you ensure that what you’re building is as close as possible to what the customer is actually looking for. You’re not only gaining a regression safety net, you’re also gaining confidence that the system is functioning as your customer expects. You’ll also gain a bit of living documentation if you’re taking care in how you write your acceptance criteria.

UI Tests? Why Me? Let The Testers Do That!

Too often UI tests are seen in the domain of the “test team.” Long years of hard knocks and struggling (or outright failing) automation efforts have finally started to bring about some much-needed change in how and where UI tests are being created. Successful teams are bringing testing and development activities and roles much closer together–and many teams are outright mixing them totally in “whole team testing” delivery flows.

Even if developers don’t create the UI tests themselves, they’re in a great spot to help the automated suites be extremely successful.

Developers can make the UI much more testable by scattering good IDs across critical elements. They can also help UI tests deal with tricky asynchronous situations by providing appropriate latches when async calls have completed. Need APIs to help leverage system functionality for test setup and teardown? Devs are all over that.

As an example, the following snippet of code will update the ID of a row in a Kendo UI Grid to be based on the ContactName text from a record:

dataBound: function (dataBoundEvent) {
    var gridWidget = dataBoundEvent.sender;
    var dataSource = gridWidget.dataSource;
    $.each(gridWidget.items(), function (index, item) {
      var uid = $(item).data("uid");
      var dataItem = dataSource.getByUid(uid);
      $(item).attr("id", dataItem.ContactName);

Bring on the Geek: Performance and Load Testing

For devs who feel general UI automation isn’t cool enough, think about a couple seriously geeky types of testing: Performance and Load. UI testing is the gateway to seeing just how well your system holds up in a real environment. Get a few UI tests in place, and it’s an easy step to begin working with CPU utilization rates, cache hits, disk bottlenecks, and time to first byte metrics.

Bringing It Home: Get Testing!

Developers can bring great value to their organizations by learning the fundamentals of UI automation. Even if developers don’t do the majority of the UI automation, understanding how the process and tools work means devs can ensure the system is as testable as possible. Devs can lend a hand in writing the automation to ensure it’s as robust as possible, and they can utilize their system knowledge to help flesh out critical aspects of the test infrastructure.

Tools like Telerik Test Studio’s plugin for Visual Studio make it simple for developers to quickly help adding value to their automated test suites. Developers can either quickly add value to automation written by testers, or they can quickly build stable, flexible automated tests themselves. Moreover, developers will see great additional features if they’re also using Telerik UI controls. Wrappers for many Telerik controls provide additional functionality to instantly verify things like row counts in Rad or Kendo UI grids, check the count of nodes in a KendoTreeView, or deal with complex scope changes of elements on the page.


Have we gotten your interest yet? In future posts, I plan to dive into the specifics for some of Telerik’s popular controls. You’ll be seeing more details around Kendo UI and AJAX controls.

Are you finding UI testing useful in your organizations? How are you working together with your testers? Let us know in the comments!

This article was originally published at http://blogs.telerik.com/blogs/14-06-04/why-should-developers-help-with-user-interface-tests-

Jim Holmes

VP of ALM and Testing at Falafel Software

Jim Holmes has more than 25 years of IT experience. He's VP of ALM and Testing at Falafel Software, the leading provider of custom software development, training and consulting services. Falafel Software customers include Fortune 500® companies like Microsoft and Shell.

More from Jim Holmes
All articles

Follow us