Project without NameMapping

[Wamboo]

Hey,

We write a project for an application written in Delphi which is a monolith. The application has been developed for over 20 years and its size is huge.

In the project we are using NameMapping which already at the beginning of the work is causing me a lot of problems and I have concerns about the size of the NameMapping file in the future.

My questions:
1) If the NameMapping file grows to a large size, is it a performance problem? By "large size" I mean about 60% coverage of our application. We have over a thousand menu items available and if I map these formats to NameMapping then won't my project work very slowly?

2) Why use NameMapping? Example:
a) without NameMapping
functionUnit1() {\pos(192,210)}functionUnit1()
var Edit = Sys.Process("pulse").VCLObject("LogOnForm").VCLObject("GroupBox").VCLObject("UsernameEdit");
Edit.Keys("YYYYYYYYY");
}
b) with NameMapping
functionUnit1() {\pos(192,210)}functionUnit1()
var Edit = Aliases.impuls.wndLogOnForm.Panel.Edit;
Edit.Keys("YYYYYYYYY");
}

Does NameMapping have any greater use than just storing the names of mapped objects? Because without NameMapping you can easily create your own variables with objects and the code becomes very readable.

3) What do you think about writing a project for such a large application without NameMapping?

4) How do you store NameMapping in the repository? SVN, GIT working in a few people with such a dynamic file is not possible in my opinion.

5) Referring to point 4 I made an attempt to divide one Project into smaller ones. I cut the project for fear that when I create one big project with a huge NameMapping file, the performance of working with this file for TestComplete will be very poor.

Example:
1) Project A -> NameMapping A
2) Project B -> NameMapping B

I find that I cannot use NameMapping A in project B. You have to connect NameMapping files and this again leads to the problem of the big NameMapping file.

Smaller projects must use elements from other projects because this is a test scenario requirement, for example: the production process module requires an index from the warehouse and the production is Project A and the warehouse is Project B.

I am currently planning to work with only one large project without NameMapping. What do you think?

[LinoTadros]

I recommend you use Name Mapping with Delphi applications.

It is not only shortning the name, that would have been silly, if that was the only benefit.

For the example you gave:

Sys.Process("pulse").VCLObject("LogOnForm").VCLObject("GroupBox").VCLObject("UsernameEdit");

What if you have that line 100 times all over your units and then R&D decides to change the UsernameEdit Control in Delphi from being a Textbox to a 3rd party editor of some kind?  Then you will have to go and change that in 100 places in your code to comfirm with the new changes.  With Name Mapping, that change needs to happen in one place only in the Name Mapping window and the actual code is never touched.

Also, Name Mapping is NOT the job of all members of the team to maintain, that would be a bad decision.  ONE person on the team needs to be the Name Mapping person for the project and then check in the .tcnm file, into source control, representing Name Mapping so that the other members of the team check it out and use it.  Otherwise, the team will spend so much time merging the file every day and waste a lot of time.

Hope that helps

-Lino

[Wamboo]

So in the application code I refer to the aliases of my elements from nameMapping and not to the elements of NameMapping itself, yes?

Can you show me an example?

What about performance if the NameMapping file is very large?

[AlexKaras · Accepted solution]

Hi,

To add to what was said by Lino:

> SVN, GIT working in a few people 

Only script unit files can be merged with the reasonable risk level. Though even this is not recommended. All other project files must not be merged by any means. Thus one of the most important tasks for you will be to split test code between different script units and assign tasks to people in a way that minimizes concurrent changes. Merging is a price that is paid for distributed development and must be avoided as much as possible.

> Why use NameMapping?

Strictly speaking, you should use not NameMapping, but Aliases. NameMapping is just a translation table between the physical objects layout of your tested application and logical organization of same objects convenient for your test code.

> Example:
> a) without NameMapping
> var Edit = Sys.Process("pulse").VCLObject("LogOnForm").VCLObject("GroupBox").VCLObject("UsernameEdit");
> b) with NameMapping
> var Edit = Aliases.impuls.wndLogOnForm.Panel.Edit;

More correct example would be:

For version A of tested application:

a) without NameMapping
var Edit = Sys.Process("pulse").VCLObject("LogOnForm").VCLObject("GroupBox").VCLObject("UsernameEdit");
b) Your test code with Aliases:
var Edit = Aliases.impuls.wndLogOnForm.UserName; // intermediate panel was excluded as it does not matter for test code

Now for version B of tested application:

a) without NameMapping
var Edit = Sys.Process("pulse").VCLObject("LogOnForm").VCLObject("LoginUsingADGroupBox").VCLObject("GroupBox").VCLObject("LoginCredentials").DevExpressObject("UserLogin");
b) with Aliases:
var Edit = Aliases.impuls.wndLogOnForm.UserName; // <== Aliased name remained not changed because only NameMapping translation table had to be adjusted for the new objects structure.

From the above example it should be obvious that with Aliases (and proper configurations of NameMapping)test code can remain the same for different versions of tested application.

> If the NameMapping file grows to a large size, is it a performance problem?

Yes it is. Thus not everything must be mapped. Best practice is to create a 'sceleton' map of your tested application and use created mapped objects as anchors for dynamic objects search via .FindXXX() methods.

[Wamboo]

Thank you for your answers.

===== Project Structure =====

If I have two files for e.g. login form or storage module:

1) one storing the mapped objects name: LogInFormAliases

and in it:

var userName = Sys.Process("pulse").VCLObject("LogOnForm").VCLObject("GroupBox").VCLObject("UsernameEdit");

2) the second one storing the action called on the form of e.g. logging name: LogInFormActions

File 2)

LogInFormActions has a reference "USEUNIT" to file 1)

the contents of file 2):

//USEUNIT LogInFormAliases

function logInUser(login) {
LogInFormAliases.userName.Keys(login);
}

This structure is valid for each module, e.g. for the warehouse or for other modules.

This way I will create small repositories with maped objects for each element and there will be no situation where one element I use 100 times and if my r&D team changes e.g. login field then I will make modifications only in the "LogInFormAliases" file.

Am I right in thinking that with such a project structure it should work properly (if of course I'm good at creating appropriate parts of the application)?

===== .Find() =====

What do you mean by creating a basic skeleton for an application?

The scenario:

I open the application -> log in -> click on the menu -> open the module -> and in it I search for an object by specific property using .find? and so on with subsequent application elements?

And only these elements I keep in NameMapping repository? Using as you suggested references to Aliases in the code?

that is:

after opening the module in the previous steps:

I am looking for .find(buttonAdd) -> the form of adding a new index to the magazine -> in this form I use again .find(Index name) -> in the field "Index name" I type the text -> and so on?

===== Repository =====

I use ImageRepository, Events and of course TestedApps in my project and I create test scenarios in Project Test Items.

How to share this elements without repository if it is not recommended?

[Wamboo]

Thank you for your answers.

===== Project Structure =====

If I have two files for e.g. login form or storage module:

1) one storing the mapped objects name: LogInFormAliases

and in it:

var userName = Sys.Process("pulse").VCLObject("LogOnForm").VCLObject("GroupBox").VCLObject("UsernameEdit");

2) the second one storing the action called on the form of e.g. logging name: LogInFormActions

File 2) LogInFormActions has a reference "USEUNIT" to file 1)

the contents of file 2):

//USEUNIT LogInFormAliases

function logInUser(login) {
LogInFormAliases.userName.Keys(login);
}

This structure is valid for each module, e.g. for the warehouse or for other modules.

This way I will create small repositories with maped objects for each element and there will be no situation where one element I use 100 times and if my r&D team changes e.g. login field then I will make modifications only in the "LogInFormAliases" file.

Am I right in thinking that with such a project structure it should work properly (if of course I'm good at creating appropriate parts of the application)?

===== .Find() =====

What do you mean by creating a basic skeleton for an application?

The scenario:

I open the application -> log in -> click on the menu -> open the module -> and in it I search for an object by specific property using .find? and so on with subsequent application elements?

And only these elements I keep in NameMapping repository? Using as you suggested references to Aliases in the code?

that is:

after opening the module in the previous steps:

I am looking for .find(buttonAdd) -> the form of adding a new index to the magazine -> in this form I use again .find(Index name) -> in the field "Index name" I type the text -> and so on?

===== Repository =====

I use ImageRepository, Events and of course TestedApps in my project and I create test scenarios in Project Test Items.

How to share this elements without repository if it is not recommended?

[Wamboo]

> SVN, GIT working in a few people
I cannot imagine working on such a large project without a version control system.
hmmm and what if I use ImageRepository and Events in my project?

This shouldn't be placed in the repository either?

How do you share your work on the project? Do you also not use version control system with files other than those containing scripts?

> Why use NameMapping?
If every module of my program is created in such a way that:

1) CashModuleAliases - in it there are variables containing the path of mapped objects
2) CashModuleActions - in this file there is //USEUNIT to file 1 and it contains the function which is then used again in the project in other file modules.

In this case, if each of my modules has such a "small" repository as a list of variables, can I assume that working without nameMapping will be good?

If the programmer changes something in the object then I also have to change the name of the object only in the CashModuleAliases file (as if I changed it in the NameMapping repository)

Am I assuming right? Did I skip something?

> If the NameMapping file grows to a large size, is it a performance problem?

Can I ask you to share an example of a feature you are using in such a search?

If I understand correctly you mean that (in the case of my application) in NameMapping I put the formats for the scenario, e.g.

Main application form ->
I click in menu ->
I open the module e.g. Warehouse (these elements should be the skeleton in NameMapping?)
and already in the warehouse module search for e.g. the "add" button using the .find() function?

[Wamboo]

Thank you all for your answers.

Example function is in topic -> https://community.smartbear.com/t5/TestComplete-Desktop-Testing/NameMapping-Alias-and-find-function/...

[AlexKaras]

Hi,

Excuse me for the brevity - I'm taking vacation with sporadic access to the internet...

> I cannot imagine working on such a large project without a version control system.

Version control system must be used for sure. But only as a storage. It is highly not recommended to use its auto-merging functionality. Ideally, there must be no conflicts when you commit your changes to the repository.

For example, a scenario like this will not work: you and your colleague get project sources to your local machines, do extensive changes all over the project during a week and then commit all your changes to the repository. This will not work.

As I said, the above approach, with the more or less reasonable risk level may be used for script code only.

For all other project entities, the recommended aproach is:

-- Check that you local project entities correspond to those in the repository;

-- Do required change (e.g. change Test Items tree structure, or do correction to NameMapping, or add script unit to the project, etc.);

-- Save changes and double-check that everything works as expected;

-- Commit your changes and notify team members to update their local copies.

Do not try to merge conflicts. With some experience this can be tried to do, but requires good understanding of internal structure of project files.