How can we implement a keyword driven automation framework in test complete for Desktop application?

1. Store objects in some XML\Excel file as an object repository and read the objects in script and perform actions?

 

This is the common method most of the automation testers following, I think this has some has limitations like below,

 

• You can't use the Extended Find[which is in-built option of Test Complete].
• You may not be able to automate dynamic objects.
• You can't descriptive programming.
• I feel Maintenance would be nightmare if we use objects in Excel sheet. 

 

2. Store it in Name mapping file? This is little risky i feel when the application(want to automate) is in development state the control properties may keep changing. Every time I may have to change object properties in script?

 

• All limitations in 1. can be done if you use Name mapping.
• Usually, In scripts we will use only the property name not the property value hence if the object type changes then only we need to touch the script.
• When it comes maintenance in objects then TC would be greatly assisted with the Namemapping with images[which is new feature of Test Complete], Advanced properties of an Object and etc,.

So overall, I would prefer Namemapping is the best option go!

 

I love be in the Automation framework development phase :) but we already crossed that stage.

 

Anyways, Enjoy your coding on your new framework.

As shankar_r, if you use NameMapping properly and use properties that don't change as frequently, then you'll find very little you'll have to update when development changes the objects. Extended find helps when object hierarchy changes and, as noted, with the new image mapping in 12.30, some of this really gets cleaned up.  Updating NameMapping is not as hard as it sounds, it just takes a bit of awareness of what kinds of properties make for good mapping.

 

Storing objects in Excel and/or XML you would still need to translate them some way into TestComplete for it to recognize how to click on, key on, or other wise interact with the objects.  You'd probably end up having to use FindChild or FindAllChildren or similar functions which require you to utilize the same sorts of properties for searching as you would end up using in NameMapping anyways.  You would end up actually having to edit automation code where as using NameMapping, all your object identification factors are in one central location.

 

When it comes down to it, when your application objects change, you'll have to make a change SOMEWHERE.  So, since the tool provides the method, seems a bit cumbersome to write your own.  Others do it, but I find that using the native feature of the tool makes for less maintenance over all.

You still need to convert the string WPFObject("window").WPF("button").click() into objects and methods to be consumed by TestComplete.  Probably the easiest way would be the "eval" of JavaScript or similar function.  But, as mentioned, that is still a step to convert that string into something TestComplete can use.  For that matter, you still haven't solved the problem of the application objects changing under development.  If the object hierarchy changes, if the class changes, etc., you still need to edit the Excel sheet at some point to match the change in the application.  There is no time save there.  

 

Editing object properties in NameMapping is actually very simple.  You don't need to remap things, just simply edit the property values and/or hierarchy.  Adding a new property, yeah, a bit more but again, no need to remap.  I don't see how it's any different than going into an XML or Excel file and editing the object strings there.

 

Also, using that naming convention, you lose the automatic "wait time" built in to TestComplete when looking for an object via NameMapping.  What happens when you perform an action and you need to wait for the object to be ready before you continue?  You'll still need to have some way of evaluating the object to be able to call something like WaitChild or WaitProperty. You lose any "flattening" of your objects... like, what you represented is a simple structure, but what about if there are other containers, etc., that your button lives in?  

 

Probably 6 one way, half a dozen the other, but regardless of how you go about building an object repository, you will still need to maintain it.  Again, I don't see any reason to reinvent the wheel and build your own when the tool has a valid feature built into it.

 

Just my opinion, really... if it works for you, it works for you... but that's why I don't think you're really helping yourself using something external. Some folks find it works, I just don't see how it is any better or worse.