GXtest Designer FAQs

Modelling Test Cases

How to make a part of the test case repeat many times?

First, you have to modularize the section you want to repeat many times into a separated test case. Then, you have to include it, and set the properties of the included test case, where you can set the number of times you want to repeat this part. You can set a fixed value, or a value taken from a Datapool. For instance, if we are modelling "Add Country" and we want to execute "add Cities" within it a different number of times acording to each country, we could have a column in the countries datapool indicating the number of cities to add to this country.

How to execute commands in grids within grids?

Better you take a look to this article Inputs in Grids within Grids.

Variables

Are the variables case-sensitive?

No, it is the same to use the variable &NumFactura as &numfactura

Are there any "reserved" variable names?

Yes, the &URLHome variable holds the default home URL of the project. Also the variable &_resultCC is reserved by GXtest, and it is used to hold the result value of a executed Custom Command. All this variables are defined in GXtest and can be used in the Test Cases.

Resultados

¿Puedo visualizar los resultados exportados a XML en el Designer? ¿Puedo almacenar y navegar en alguna forma los resultados de ejecuciones previas?

GXtest Designer tiene el objetivo de preparar las pruebas a ejecutar, y no de ejecutarlas. O sea, da la posibilidad de ejecutarlas y de visualizar resultados sólo con el propósito de asegurarte que las pruebas que se están armando funcionan correctamente. No es la idea el almacenar esos resultados.

Para esto existe el GXtest Manager, que es el que administra el repositorio de pruebas y permite agrupar los Test Cases en Test Suites y agendarlos para ejecutar. Los resultados de estas ejecuciones quedan almacenados en la base de datos y pueden ser navegados desde este componente.

GXtest execution speed

Why does GXtest execution take more time than other automated tools?

All modern web applications use Ajax technology, which means the app process the user actions through requests "behind" the web page, while the user interacts with the UI. For example, the input of a value in a certain field may fire a validation request against the web server, and eventually the app may show a message to the user when the validation is completed. This produces a richer experience for the web user, but it makes it harder for the common automated tools to successfully run the functional tests.

For example, when we are in a register form for a new user, after we input our email address, the system checks if that address is not already registered. That call to the server may last from a few milliseconds to some seconds, and it is executed "behind" the browser UI. If we need to verify in our test case that a message is displayed (something like "this email is already registered"), the test execution must wait for the call to the server to be completed. Bear in mind that there is nothing that tells the automation tool that it must wait for a request to be completed, so in this case many of the all the automated tools fails. As a workaround, the tester must enter in the test case manual pauses with a fixed time span, so the execution waits for the application to respond, but this solution makes the test case less robust, and it tends to fail if the system is responding slower than usual.

GXtest instead, knows exactly when an ajax call is completed and when a pending request exists, because GXtest is specifically designed for GeneXus applications, and knows how to "talk" to the system. This feature definitively helps the tester, who can forget about manual pauses and time-depending test cases, as GXtest takes care of this automatically. As a downside, GXtest execution may take more time than other automation tools (in particular in remote or slow applications), because it waits for the requests to be completed so the validations can be executed with all the information needed, and without obtaining false-negative because of slow system response.