System Components - Details to consider before conversions

Introduction

This page is to specify various conversion details concerning the conversion of Askida CT / Alithya GoTest's data from release 2.17 to 3.00.

1 - Private/Restricted Combined Keywords using the same named argument name as a project variable

In a private/restricted combined keyword, it can be possible to name an argument the same name as a project variable.

Due to this, the behavior would be the argument's value becomes a local variable and have priority over the project variable.
However, after the conversion of the project variable reference to ${MyVar} to ${root.MyVar} (or equivalent), the argument's value will be ignored and always use the project variable instead. 

Example:

The easiest solution is to rename both the argument's name and all variable references to the ones that doesn't have a global variable of the same name.

Possible solution:
 

2 - Deprecated Selenium keywords that no longer exist

The following deprecated Selenium keywords no longer exist in Alithya GoTest 3.00's Selenium libraries :
 - Select Window
 - Locator Should Match X Times

Thus they must be MANUALLY replaced by the scripters before the conversions :
 - Select Window –>  Switch Window
 - Locator Should Match X Times –> Page Should Contain Element

It can be simple to use the Global Search to search for those used keywords in the scripts.

See screenshots for manual ajustments :

1) 

2)

3 - Public Combined Keywords using project variables

It can be possible that some projects use public Combined Keywords that uses project variables.
Initially, it can work for the scripters since the variables are memory-generated before using those Combined Keywords.

However, with the conversion, it won't update the public Combined Keywords's variable references to those project variables since those Combined Keywords are supposed to be independant.
In addition, if there are multiple projets with each their own variables' different values, there is no simple automatic way to solve this.

A solution is to change those public Combined Keywords into restricted Combined Keywords.
Thus, the restricted Combined Keywords are bound to a project and can logically link to a project's variables.

4 - Scripts using variables of Internal Robot Framework but also have project variables of the same name

Some scripts can use some Robot Framework's specific variables such as ${None} (represents null in Robot Framework).
In release 2.17, even if a project variable as declared as "None", Robot Framework ignores the project variable in favor of its Internal Variant.

However, after the conversion, if a project variable existed, the renamed reference (ex : ${None} to ${root.None} ) will use the project variable instead of the Internal Variant.

Example #1:

Example #2:

Solution:
Rename any project variable of this type to another name WITHOUT changing script references.

5 - Variables references of exact names but with underscores or space differences can match project variable

For a project variable, it is possible to refer and use a variable if it is the same base name but with underscores or space differences.
However for the conversion, those alternatives references are not be converted.

Example:

6 - JSON resource files used in combined keyword's arguments but also used in json() can convert incorrectly

In some cases, if a JSON resource file is used while there is also the same  relative variable name using ".json()", it can convert incorrectly.
For example, having an combined keyword's argument called "createAccounts.json" while having part of a variable use called "CreateAccounts.json()" in its keywords.

Exemple before :

Example after :