GXtest ExtensibilityA very important feature for a tool to have is its possibility to extend its functionalities and interoperate with its components. This allows users to add new functionalities or just take into consideration data of their specific situation.
GXtests currently provides two extension mechanisms; one mechanism consists of adding Custom Commands and the other one of calling GeneXus procedures to add validations and/or actions to the application being tested.
For GXtest,
commands is the name for the way of describing the actions a user can perform in the browser. There are, then, a series of commands that allow you to describe (in practical terms) all the actions a user can perform with a GeneXus application.
However, on some occasions certain sections of the application are developed outside GeneXus, adding a specific javascript or something similar. In these cases, standard commands may not be useful, and a Custom Command must be developed. These are added in GXtest by entering the name you want to give to them, the type (action, event or validation), a description for the parameters and the javascript code that implements the user action. This command is then listed as a standard command and the user can't tell a standard command from a command developed through this mechanism.
Another mechanism is the possibility to add calls to GeneXus procedures. For example, if you want to validate an application status at a data level after a series of interactive actions, the best thing to do is to add a GeneXus procedure to which you can pass the necessary parameters (for example, customer number, invoice number, etc.) and which returns whether or not the status is correct. They can also be used to load data that will be provided as input in tests.
These procedures can also be used as functions which can be an interesting feature to have in a test tool, such as generating a random number, generating a random string, concatenating strings, etc. If a processing can’t be carried out through GXtest, a GX procedure can be implemented to solve that feature.
To be able to call a GeneXus procedure, the procedure must be accessible through WebServices from the machine where GXtest is being run. To add a procedure, you enter the name, type (action or validation), description and url to the WSDL (this allows the procedure in and out parameters to be read). After the procedure is added, it becomes accessible to the user in a transparent way (like the custom commands).
In the next post we will talk about interoperability, we will try to open the possibility of generating test cases from “outside”, or expose services in GeneXus’ IDE.
What other mechanisms would you like us to consider?