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.
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.
> 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.
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.
