GXtest Generator - Test depth

The Test depth option specifies the data complexity that the generated Test Cases will have. The number of rows that the generated datapools will have depends on this configuration.

Configuration options

• Minimum
• Basic
• Basic with rules
• All discrete values
• Valid and Invalid

Each configuration is explained in the following sections of this page.

Minimum

It generates only one value for each editable field of the entity analized. The value may be ramdomly generated, or could be taken from a Dictionary or the application database.

Basic

It generates a set of valid values for each field, based on the border values of those fields. For example, for a Numeric(4) field, it could generate the following values: 183, 0, 1, 9999 The value generation logic is based on the boundary value analysis technique.

Basic with rules

Same as Basic, but also includes border values based on the GeneXus rules of the analized objects. For example, if we have an error rule over the field "Age", such as the application will raise an error if the age entered by the user is greater or equal than 120, then GXtest Generator will choose the number 119, as a good boundary value to test.

The rules that are currently analized/supported are the ones with comparisons versus static values:

• error() - when the error depends on a numeric attribute comparison
• error() - when the error fires if the length of a string is greater or lower than a numeric value

All discrete values

(Supported on GXtest 3.0 or greater)

This configuration is particularly applied to fields where the user can only select one input from a discrete set of values. The best example is a combobox, where the user can choose one option from a restricted and predefined set. If the configuration "All discrete values" is selected, GXtest Generator will include in the test case all the options available in the combo (instead of only selecting a subset of values).

Valid and Invalid

(Supported on GXtest 3.0 or greater)

Besides the tests that goes through the normal flow of the application, GXtest Generator will create a "red flow" test case. This test case will check that the error messages associated with the validations of the inputs of a form are correctly displayed.

The test case will have the following steps:

• Fill all inputs with valid data
• For each error rule associated with an input field:
  • Fill with an invalid value
  • Verify that the message displayed matches the error rule
  • Fill with a valid value

For example, if we have a rule over the Age field: error("The age must be lower than 120") if Age>=120;

First, the test case will fill the Age field (FillInput command) with the value 120 (or bigger), and then it will verify that the error message appears on the screen (VerifyControlValidation command).

So, GXtest Generator will write in the test case the following commands:

FillInput(Edad, 120)

VerifyControlValidation(Edad, "La edad debe ser menor a 120", Error)

FillInput(Edad, 20)

The first two commands will do the validation on error, and the third command will fill the editable field with a correct value, for the case when we have other fields that we want to check, so the error on this field do not interferes with other error messages and validations.

When the error rule has a complex logic for determine the error result (for example when a Procedure is invoked), GXtest Generator will create the commands, but the values to be used must be completed by the user/tester. This is because GXtest may not know the correct or invalid value for those inputs that depends on complex logic or dynamically generated data, but for sure the tester knows what values are good to put in each case, so GXtest generates the commands, so the user only needs to complete the data.

The data that GXtest Generator could not determine, would be easily identifiable in the associated datapool, because they will have the values "Fill with an invalid value here" and "Fill with a valid value here".