As you’re automating, you may discover that some objects in your application have been customized based on your company’s business needs. During your manual tests, you may have interacted with these custom objects without ever being aware of them. However, these objects can cause issues in your automated tests if you aren’t prepared for them. Let’s look at a quick example.
Here’s a simple application with two buttons. See anything special about those buttons?
Exactly. To an end user, those buttons don’t look like anything special. In fact, you probably won’t look twice at them until you discover your automated tests fail to work properly against those buttons. Even though to you and I the buttons look normal, remember that your computer sees your application very differently. In this case, button2 is actually a custom built object; it’s not a normal button. As such, TestComplete doesn’t know how to work with it.
So how do we rectify this?
Let’s start by using the Object Spy to look at the button in question. You can see its ClrFullClassName is SmartBear.ObjectSamples.CSharp.Button. That tells us the name of the custom class, and that this button is based off of a standard windows button. Note that with some controls, it’s not as obvious regarding what class from which a given control is based. In this case, it’s best to ask your developers.
Armed with this information, we need to tell TestComplete to treat all instances of our custom button class as a standard button. To do this, go to Tools>Current Project Properties and select Object Mapping.
Expand Win32 Controls and Windows and Select Button. Then click the Add From Screen button on the right side of the window. That’ll bring up a dialog with a finder tool. Just drag the finder tool over the custom button and release. You’ll see the button’s class name has been captured in the dialog. Click OK, and now every time TestComplete encounters an object of this type, it will treat it as a standard button.
TestComplete can work with many types of custom objects, from many different vendors. Whether it’s a button, a Flex DataGrid, an Infragistics UltraListView or more, we can handle it. Have a look through the list of supported object types shown on the Object Mapping screen and then work with your developers to determine which one makes the most sense to map back to. The end result will be more reliable, stable automated tests.