Best Practices automating with GXtest

In this article you will find some practices considered good ones when you automate your test cases with GXtest. Anyway, you should define your own according to your projects.

Nomenclature

It is important to define a classification of test cases and folders. This practice is simple but results in many benefits. It is suggested to name test cases with the goal of distinguish those that are designed as components from those other that are thought including the components in cycles. Those ones that are used to orchest test cases can be called as Cicle<accordingName>

On the other hand, it is useful to define a folder structure that allows you to separate the general test cases (typically login, access menus, etc) from the test cases of the various modules.

Often test cases are just temporary, they can be named with a common prefix as tst<name> or tmp<name>.

Comments and Descriptions

Each test case and datapool can have a description saying in general what is its goal. Also, test cases can include comments that illustrate the various steps in the test case. It is suggested to include a column in each Datapool if you want you add a comment for each data to be used in the test cases.

Reusable Components

One of the main advantages of GXtest is the ease to reuse test cases. To fully get the advantage of this quality it is important to define which ones are the test cases that will be reused, which input and output variables and Datapools will be used. Then you can build the main test cases (cycles) simply nesting test cases.

Validation's descriptions

Each GXtest validation has an extra field in which you can include a description to be displayed in case of failure. This description is very useful to analyze the results of an execution.