The Importance of Migrations in GeneXus Development
Version migrations in GeneXus commonly include enhancements relative to the automation of the development process.
In this article, Mariana Falabrino, from the Customer Success department at Abstracta, describes the steps to automate unit, web UI and mobile UI tests with GXtest, the product jointly developed by Abstracta and GeneXus to design, implement, and run functional tests in web and mobile applications.
In this case, a multi-platform banking system that manages accounts, users, credit cards, and transfers was used as an example.
“We will run the unit test after building the application. Next, we will run the interface tests when we deploy the application to get early feedback on the state of the app, fix bugs early, and quickly deliver value to the customer.At first, we are going to run these tests at the IDE level after building our app. To do so, we have a property to configure the automatic execution of the tests after a Build all of the KB. Remember that the tests’ value grows exponentially when they are executed in an unattended manner in a pipeline, after building and deploying, with almost immediate feedback in each deployment of the application,” explains Ms. Falabrino.
To fully understand all the details, watch her presentation titled Software Testing with GeneXus at GeneXus Live.
Below are the different types of tests that can be automated in GeneXus. In this example, the creation of a new transfer will be automated and the balances of the source and destination accounts on the different platforms will be verified. The objective is to ensure that this functionality is not broken when changes are made.
This functionality will be verified in different test layers:
1- Unit test
First, a unit test will be created to verify the behavior of a procedure that approves or rejects the transfer depending on the balance of the source account.
2 – Web UI test
Next, a UI test of the scenario will be run, creating a new transfer and validating the balance of the source account before and after the transfer is confirmed.
3 – Mobile UI test
Lastly, a UI test will be run on the mobile application. It verifies the balance of the destination account for the transfer that was previously made.
The purpose of these tests is to verify the core business logic. To make this validation, it is recommended to encapsulate the business logic in procedure objects.
This is done in two steps:
Step 1: Generate the unit test
“To verify the behavior of the CheckBalanceForTransfer procedure with different input data, it is necessary to create an automated unit test. To do so, select the Create Unit Test option and enter the test data that will be used to run the procedure. In this way, the Unit Test object is created with a template ready to be executed.This template runs through the different test sets, executing the procedure to be tested and validating the expected results with the actual results of the test data.”
Step 2: Load the test data
“What is left is to set the expected values, running the Unit Test by selecting Run Test(s). The Unit Test object has the same power as a procedure. You can add validations to the database, call functions, add variables, and call other procedures. Here the details of the run are displayed in the results panel.Also, you can run the tests again and view detailed information of the test coverage and of each of the assertions executed.”
The objective of the web UI test is to verify a scenario in a deployed application. To implement it, the flow to be automated must be recorded and then executed in a browser.
“A UI test simulates the interaction between the user and the application by performing the added validations.
It can be executed in different browsers. This information (browser, version, date, and execution of each command together with the assertions added in the flow) are displayed in the results panel. Interface tests should be implemented in the most risky flows of our business in order to catch bugs early and accelerate our development cycle,” says Ms. Falabrino.
Step 1: Open GXtest Recorder
“Select the option Record Web UI test. This will open GXtest Recorder, which captures the different actions executed on the application and returns the GeneXus code script.”
Step 2: Record the flow
“When the recorder is enabled, you have to enter the application URL and implement the actions to be automated. In this case (watch video), I created a new transfer, added the validation of the source account balance before confirming the transfer, confirmed the transfer, and added another validation of the source account balance after confirming the transfer.”
“We will stop the recording, copy the GeneXus code script and take it to the IDE to run in different browsers.”
Step 3: Take the GeneXus code to the IDE
“With the web UI test script in GeneXus code ready to run in each deployment of our application, we can now run it from the IDE by right-clicking on Run Test(s). This web UI test object has the same power as a procedure object since you can add variables for data handling, database validations, procedure and function calls and everything you need to improve your UI test.”
The objective of the mobile UI test is the same as that of the web UI test, which is to simulate the user flow in the app. You can then run the same flow on different devices and validate that it works correctly in all of them.
“To generate a test, you have to write the code in the IDE and run it. Here I will only run it because the code has already been written.”
Step 1
“In this mobile UI test, the login is made in the application. In addition, it verifies the My Accounts text and the balance of the destination account of the previous transaction, which in this case has to be 200 dollars. To do this, select the Run Test(s) option. This object, like the Web UI Test object and the Unit Test object, has the power of a procedure object and allows adding the necessary database validations.”
Step 2
“Once the above process is complete, the test is run in the simulator replicating the user flow. Then it logs out and finishes running the test. In the IDE we can see information of each of the commands that were executed. The mobile UI test is now ready to run whenever we deploy our application.”
Leave a Reply