Forum Discussion

Wamboo's avatar
Wamboo
Community Hero
6 years ago

Project without NameMapping

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 NameMa...
Name Mapping
  • AlexKaras's avatar
    AlexKaras
    6 years ago

    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.

     

AlexKaras's avatar
AlexKaras
Champion Level 3

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's avatar
Wamboo
Community Hero
6 years ago

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?