Forum Discussion

hanumantha's avatar
hanumantha
New Contributor
10 years ago

Need help to automate with Test Complete

Hello,

I am new to Test complete with rich experence in other automation tools.

I need some help in automating web application.

 

1.I need to achive something like this.

browser("").page("").Webedit("SomeProperty1=Somevalue1","SomeProperty2=Somevalue2").Click.

Note that,this object is dynamic and properties are bound to change and objects are not stored in Object repository.

I dont want to use Find method.

 

2.How to write keywords in Test Complete.

something like

ClickOnButton(Property of button){

Browser().page.WebButton("property Passed").click

''I dont want to use find method,here and dont want to use object mapping.

}

 

 

 

 

 

 

 

  • Colin_McCrae's avatar
    Colin_McCrae
    10 years ago

    I use a combination.

     

    I map high level objects (pages, tabs, larger areas - such as main panels - within pages/tabs, some tables).

     

    Using those as a starting point I use things like FindChild, FindAllChildren and helper functions (where the logic to find things is more complex than the find methods allow for).

     

    I've used this analogy before, but think of it as a book.

     

    If you are looking for a single word in a book, starting at page 1 and looking through EVERY chapter/page/paragraph in a book sequentially will be slow.

     

    However, if you know what chapter the word is in, you start looking there. If you know what page within the chapter, you would start there. If you know which paragraph on the page, start there. Etc. Each level down cuts the search and so speeds it up.

     

    Also, higher level objects tend to change less frequently, and give you less to maintain. You *can* map all objects, if you want, in with certain types of  applications/languages, I find it easier/essential to map lower level controls as they don't contain enough information on their own to be found dynamically at run time. By this will vary depending what you're testing. For web stuff, I use the above approach of map high level, find low level.

  • Colin_McCrae's avatar
    Colin_McCrae
    Community Hero
    10 years ago

    Short answers:

     

    1. If you are not mapping objects, and your application/object is dynamic, you pretty much have to use a "find" method/function of some description. If your properties change, and you are telling it to use an object based on a parameter that you change when it changes dynamically, you are effectively doing a "find" anyway? browser("").page("").FindChild(Propertie(s), PropertyValue(s), Depth, Refresh).Click .... will pretty much do what you want. (http://support.smartbear.com/viewarticle/69449/) Personally, I wouldn't do it this way. Doing "finds" at such a high level of a page can get pretty slow if your site has a large DOM.

     

    2. You mean build a keyword driven framework? Thats not a simple question. And you're not going to get a miracle one reply answer I'm afraid. I have a framework to allow user driven keyword + data driven tests. But thats an entire framework built and developed in house.

     

    If you are familiar with other automation tools, and decent quality scripting in them, you should be familiar with the concept. But you'll need to set up a framework that suits your needs. There are numerous ways of doing it. I use script extensions and Excel datasheets (via COM, I find DDT too limiting) to drive mine. I imagine others do it completely differently.

  • hanumantha's avatar
    hanumantha
    New Contributor
    10 years ago

    Thanks Colin.

    Then, what would be your approach to deal with larger DOM?

     

    Thanks,

    Hanumantha

    • Colin_McCrae's avatar
      Colin_McCrae
      Community Hero
      10 years ago

      I use a combination.

       

      I map high level objects (pages, tabs, larger areas - such as main panels - within pages/tabs, some tables).

       

      Using those as a starting point I use things like FindChild, FindAllChildren and helper functions (where the logic to find things is more complex than the find methods allow for).

       

      I've used this analogy before, but think of it as a book.

       

      If you are looking for a single word in a book, starting at page 1 and looking through EVERY chapter/page/paragraph in a book sequentially will be slow.

       

      However, if you know what chapter the word is in, you start looking there. If you know what page within the chapter, you would start there. If you know which paragraph on the page, start there. Etc. Each level down cuts the search and so speeds it up.

       

      Also, higher level objects tend to change less frequently, and give you less to maintain. You *can* map all objects, if you want, in with certain types of  applications/languages, I find it easier/essential to map lower level controls as they don't contain enough information on their own to be found dynamically at run time. By this will vary depending what you're testing. For web stuff, I use the above approach of map high level, find low level.