Often when you start out with TestComplete you’ll find yourself bewildered by the complexity of identifying and naming the objects in the application you’re testing. TestComplete has a lot of powerful features to help with identifying objects in applications but when you’re starting out you’ll want to get to grips with the basics. The next few posts look at good approaches for mastering Name Mapping in TestComplete.
If you want to understand ‘why’ we have name mapping then this into article is a good place to start. If you want to understand ‘what’ name mapping is then read on. Or if you just want to find out ‘how’ to get started then we’ve got another post coming up soon.
When we start out we’ve got a system that looks like this to TestComplete:
What we need is a view or perspective on this that focuses on what we’re interested in for our tests. Something like this would be much easier to work with:
What’s in the Object Browser is exactly what TestComplete sees it at the system level. If you really wanted to you could even use the full system names to identify the objects in your tests. So for example if you use the object spy to identify an object you can see the full system name for the object.
You can then select the ‘Show in Object Browser’ button and you’ll see the object in the objects list in TestComplete. It’s this “Sys.*” name that you can then use in your test steps if you want to:
Sys.Browser("iexplore").Page("https://www.zoho.com/crm/lp/login.html").Panel(0).Frame("zohoiam").Table("outertable").Cell(1, 0).Panel("loginform").Form("login").Table("inntbl").Cell(0, 0).Table(0).Cell(2, 1).EmailInput("lid")
It’s not normally wise to use this though. The problem with the full system name is that it changes. It’s also difficult to understand because it’s so long. There are much better ways of identifying objects too.
Just bear in mind that this is where it all starts. It’s the foundation that the Name Map is built on. Think of the Object browser as the lowest layer. Then think of the TestComplete Name map and mapped objects as a layer on top of the Object Browser. When the Name Map is laid over the Object Browser it hides a lot of the chafe and complexity that you’re not interested in.
When you’re writing automated tests all you want to focus on are the objects in your application that you’re interacting with. So that you can focus on just the objects you’re interested in, the Name Map ‘Mapped Objects’ are picked out of system Object map. What you see then in a cut down list of mapped objects which are the objects you’re interested in for your testing.
So for example when you record a test, TestComplete will populate the name map with all the objects that you’ve interacted with during that recording. All the other objects on the system are ignored. Thus you get a clearer, more focused list of objects that you’re testing with.
That’s not to say TestComplete will give you a completely clear and focused list. TestComplete takes it’s best guess to identify the objects you interact with and map them. It’s not a mind reader though. It will map absolutely everything you interact with not just the objects you’re really interested in. TestComplete will also record the full paths to these objects which can be a little unwieldy. For example:
Not exactly easy to type if you have to refer to this object many times in your scripts. Having said that it’s a big improvement over the “Sys.*” object name. In fact TestComplete has taken some steps to reduce the complexity of the naming by removing some of the container references which helps a bit too (e.g. levels like Table(“inntbl”) have been removed).
Where does this leave us? Well we started out with this….
Sys.Browser("iexplore").Page("https://www.zoho.com/crm/lp/login.html").Panel(0).Frame("zohoiam").Table("outertable").Cell(1, 0).Panel("loginform").Form("login").Table("inntbl").Cell(0, 0).Table(0).Cell(7, 1).Button("submit_but")
And now we’re down to this…
Notice also that the reference starts out with the string “NameMapping.*”. Mapped objects start with “Sys.*”. The “NameMapping.*” naming convention can be used now in your scripts to identify that you’re refering to objects that are listed in the Name Map.
To make our lives even easier, and to avoid these long “Sys.*” and “NameMapping.*” naming conventions you can also make use of Aliases.
Aliases allow us to put another layer on top of the Object Map and the Name Map. So this final layer on top simplifies things even further.
This simplifies things for 3 reasons….
1. You can change the name of objects to make them more meaningful
So for example you can take the name “emailinputLid” that your developers used in the application and change it to “EmailTextBox”.
2. You can manually remove layers of the heirarchy/path to simplify the path name.
So for example you might have a long path in the Name map and then modify this in the aliases to shorten it to something more logical. So you’d go from …..
3. You can rename items in the hierarchy/path
So these parts of the path that are left still look a little unweidly. So we can manually go in and rename parts of the path. At this point we’ll take this..
and rename to give us
Far more readable and meaningful when used throughout out keyword and scripted test cases.
We’ve set out with a system name of….
Sys.Browser("iexplore").Page("https://www.zoho.com/crm/lp/login.html").Panel(0).Frame("zohoiam").Table("outertable").Cell(1, 0).Panel("loginform").Form("login").Table("inntbl").Cell(0, 0).Table(0).Cell(7, 1).emailinputLid
Then we’ve reduced it down with Name Mapping and Aliasing to end up with..
It’s not difficult to see just how much easier it will be to write and read our tests with the Alias naming convention rather than the full System naming convetion.
Up next: Using the name map properties pane to identify the objects reliably.