Forum Discussion
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.
- Marsha_R7 years agoChampion Level 3
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 agoANW