How to access Extended object properties in TestComplete

UI testing is a very tricky thing. Everything depends on how accurately test tool recognizes UI elements and theirs properties. In this particular topic I would like to tell you how some invisible and not obvious settings of TestComplete can improve recognition of UI object properties.
TestComplete with default settings does not always have access to Extended properties of these UI elements:

You can change it by going to Tools > Current Project Properties > Object Mapping and check the required component there (if it is supported by TestComplete).

After this you will be able to see additional category “Extended” in the Object Spy and access these properties in your test scripts:

The only one thing you should take into account is that the designer of the Object Mapping tree was probably drunk or used a very heavy drugs. In some cases it is not enough to check the object category (I spend several days by trying to configure support of our DevExpress XtraGrid component). In the picture below you see that XtraGrid component is checked:

but TestComplete Object Spy still doesn’t show the Extended properties. Expanding the XtraGrid shows that not all controls are checked

After checking them you will get expected Extended properties.
I hope it was helpful for you.

Comments

Post a Comment

Popular posts from this blog

QA Chapter

There are different point of view on organising a QA chapter. As a QA manager, I see it in the following way. If you ask me ` How  should  QA Chapter look like?` , I would suggest the following structure: Chapter Lead: Person taking final responsibility for decisions Mandatory: 3 QA engineers, 1 BE engineer, 1 FE engineer Optional: Product Owner, Architect, DevOps engineers NOTE: It is very important for me to have representatives of different roles in the chapter, since everyone sees how to improve quality and where to apply improvements differently.  If you ask me ` What  are  QA Chapter  areas of responsibility ?`, I will answer that the agenda of QA Chapter meetings should be based on the following areas: Product quality: Quality of Development Quality of Testing Quality Control Quality of Delivery Visibility of QA work If you ask me ` How are you going to make your QA Chapter performing well?` , I will answer that we will need to define a set of rul...
Read more

Organizing UI automation testing

In recent years it is becoming less and less companies where you can meet dedicated test teams working with different development teams under the same product. This is most likely due to financial reasons because there are not so many companies who can afford to keep a team dedicated exclusively to testing and everything related to it. Nowadays a majority of software development companies work using Agile & Scrum, where all team members (software engineers, architects, programmers, analysts, QA experts, testers and etc.) are sitting together and doing their best to meet the goals of the sprint. In such projects testers, in principle, may know nothing about work of their colleagues from other teams because their areas of responsibilities intersect not very often or do not intersect at all. It can work fine until we are not starting talking about organizing automation testing and everything related to it: planning, design, implementation of frameworks and tests, support. I ...
Read more

Why do you write automated tests?

Why do you write automated tests? Many people say "to find bugs" but it is not true. Tests are not looking for bugs. They just verify correspondence of actual and expected results. - So? Where is the “looking for bugs” here? -No, I haven’t seen. Some time ago I had a conversation about unit and integration tests with one of our developers. In the result we've come to conclusion that they are writing tests to verify contracts between components for convenience, access, usage of the defined data types and some other aspects. When you are writing a new code the test will be your first client. If it is easy and comfortable it means that everything is fine.When you are writing test on existing code but facing issues all the time and have to write a lot of workarounds it means that existent code is crap and it requires improving it. The same is applicable for other automation tests written by testers. You are writing them on the framework which works with the application...
Read more