Forum Discussion
Hi,
From the technical point of view, there is no limitation on the number of (temporary) project variables. (Well, at least no one reported such problem here yet.)
However, XPath and Page Object are far not the best practices in TestComplete's world.
It is much better to use .FindXXX() and .WaitXXX() methods provided by TestComplete (.FindChild(), WaitWindow(), .WaitButton(), etc.) instead of XPath.
TestComplete provides you with Objects Tree that is effective replacement of the Page Object model. And exceeds it if NameMapping and Aliases are used. https://support.smartbear.com/screencasts/testcomplete/reliable-tests-for-dynamic-objects/ is a recommended video to get a good understanding of NameMapping and the whole https://support.smartbear.com/screencasts/testcomplete/ page is worth to be bookmarked as well.
One more note: Unlike Selenium, Appium, ..., TestComplete provides fantastic documentation that is really worth detailed reading. At least, I would recommend to go through the description of every function that you will use in your test code to get better understanding of how it works and be aware about its specifics.
A little-bit extreme summary: the sooner you will forget about Selenium practices and move to Aliases and .FindXXX() the better will be your test code. :)
AlexKaras wrote:
A little-bit extreme summary: the sooner you will forget about Selenium practices and move to Aliases and .FindXXX() the better will be your test code. :)
Couldn't agree more. TestComplete has a built in feature that takes care of object identification for you. There is no need to "reinvent the wheel" and construct a POM within TestComplete, at least for object identification.
Now, you can still go the route of having classes and code units for each page containing methods for executing tests and actions against components on those pages, but I'd strongly recommend that those units only contain the method code, not object identification code. Use Aliases to build out your object structure you want to use and reference those aliases in their method code.
cunderw, don't you do something like this in the framework you demonstrated at Connect? Perhaps you could speak to this a bit.
- cunderw7 years agoCommunity Hero
Yeah absolutely. Basically they way I go about is to map top level components, tables, panels, etc...
Then you have action script units for each sub application / page that handle finding inputs, buttons, data from tables etc.. using find methods. These are used as building blocks for tests, no local or individual actions are handled by the tests themselves, they just call these utilities in the order needed for the tests. This allows you to update object properties and even entire flows, data and field validations etc... in one single place to keep all of your tests working.
- AlexKaras7 years agoChampion Level 3
> way I go about is to map top level components
This is the key that I meant: main skeleton elements are mapped and Aliased in a convenient way from the end-user point of view. Then those skeleton elements are used as starting points for the dynamic elements (like table cells) that are sought for via .FindXXX() methods.
Such design usually results in good maintainability, flexibility, maintainability and performance.
- Marsha_R7 years agoModerator
Yes to all of that ^^ :)
Use your name mapping for the minimum number of objects that you have to have to get started, then Find the rest.
I still ended up with a large number of project variables, but that was because of the calculations we needed or values passing from one test to another, not for objects.
Related Content
- 14 years ago
- 10 years ago
Recent Discussions
- 7 hours ago