getting to know: TestComplete Desktop (2) – SUT & first test

SmartBear headquartersI am currently evaluating TestComplete Desktop for an upcoming project. In the first post of getting to know: TestComplete Desktop I gave a quick overview of the SUT I’m going to use and wrote about my expectations for TestComplete.

In this post I will write about the SUT and the first test automated with TestComplete.

application under test

As previously described I wanted to create my own WPF sample application for full control over the automation-relevant properties. So far the sample application has a working UI built with the MVVM pattern (I had to refresh my WPF knowledge with Rachel Lim’s Blog) and is named application under test. Server & database connections will be added once I need them.

Although I might not win any design awards with application under test, I am satisfied with the controls & WPF bindings. The application consists of 3 pages:

#1 home page
The home page holds a static data grid to test TestComplete’s ability to access data grids.
home page
#2 customer page
The customer page lets you enter a customer’s id. If that id is >0, the load button is enabled. After you click on load, the values of the customer are displayed. A combo box is provided to test accessibility.
customer page
#3 product page
The product page works the same as the customer page.
product page

getting started

Upon starting TestComplete, a window suggests to read the Getting started section of the integrated help with some pages of basic information about

  • automation in general,
  • TestComplete concepts & UI,
  • supported test types (I am curious about TestComplete’s unit testing capabilities?), and
  • that a verification is called checkpoint in TestComplete.

So far so good. Knowing Ranorex, I am familiar with building an object repository and using those objects in keyword-based test scripts.

recording the first test

It’s often a good idea to use an automation tool’s recording capabilities to get a first impression of how the tool works and what a test will look like. So my first test will be a recorded keyword test. The test VerifyProductPrice

  • navigates to the product page,
  • enters the product id 1,
  • clicks on the load button, and
  • verifies that the price is 12.

first test as recorded
Each action step of the test consists of an item (e. g. TextBox), an operation (e. g. SetText) and a value if needed (e. g. “1”).
The checkpoint’s value specifies the object and the check to be performed.

running the first test

… failed. I just recorded the test and it does not work. That’s why I am no fan of record & playback. If you don’t know what happens behind the scenes and if you don’t put at least some manual work into robustness, you won’t get anywhere. These are the problems with my recorded test:

#1 Unable to perform the action because the control is disabled.
The SetText operation does not cause the product id text box to evaluate its data bindings. The view model is not notified of the input and the load button remains disabled.
Solution: I substitute the SetText operation with a Click and a Keys operation. The text box no longer gets its text set but receives keystrokes and the data bindings do their magic.

#2 The wText does not equal “12”).
As described in my first post, I wanted to start without giving my UI any names or automation ids to see, what happens. Well that’s what happens! TestComplete identified all of my text boxes as “the text box in the window”. So instead of checking my price text box, TestComplete checked another text box.
Solution: I am going to make my controls accessible and build my own object repository

(no) fun with AutomationId

To make my controls accessible, I provide a name and an automation id in the XAML files. I don’t want to use the name for automation, though: A control’s name is owned by the developers. The automation id, on the other hand, is owned by the testers.

I open the object browser and navigate to a text box – but there is no AutomationId property…
object browser
After some reading I know why: The attached UIAutomation properties are not provided by default. I activate the feature and there they are. I manually build an object repository by identifying each control by its automation id and substitute the items in the test: Voila, my first running TestComplete test:
object repository
first test refactored


The easiest way to create a test in TestComplete is done via the graphical UI. It allows you to build an object repository by identifying the required controls via their properties. To create a keyword-based test, those objects are combined with operations and values. To use the attached UIAutomation properties you need to manually active a feature, first.

You should always at least refactor an automatically created object repository to increase the robustness of the automation.

One more thing that took me some time to figure out: If you want to make direct changes to a cell in the Value column, select the row and click the cell once. If you perform a double click, you will open the corresponding configuration dialog instead.
change value

coming up

Next time I want to automate some more controls and start increasing the efficiency by going data-driven.

October 5th, 2016 by