A unit test is one of the crucial parts of the Software development Life Cycle which is intended to ensure the behavior and functionality of a specific section of the application.
⋮IW has been working with TIBCO since 2004, and by employing the knowledge and expertise that we have in the field, we have come up with the idea to create our internal supporting tools to accelerate development, reduce the time needed for unit testing and automate certain features for extracting and building messages.
In this article, we will describe step by step the behavior of each of ⋮IW supporting TIBCO BW productivity tools.
All of the tools are related to XML-based messaging for Soap Web Services or Rest APIs which provide certain functionality to every tool for the desired resources and we are referencing those resources from an external Excel file.
As a group of integration developers, we have decided to use a certain naming convention for each tool with the same coding standard build in Java Eclipse with additional public libraries.
Two of them are platform-independent and the other two are coupled with one of the most famous open-source testing tools called SoapUI. We will describe the functionality of SoapUI in the following sections.
We will also discuss more granularly each of the following tools:
At the beginning of the article, we have also mentioned that we are using an Excel file for managing and controlling the desired outcome for each tool where dozens of columns are specified. Every tool consists of separate Excel files where each column contains description and placeholder where we can specify XML element, optional elements, optional attributes, recursion depth of the elements, desired XSD or WSDL, name of the message, operation, and target directory.
A test message generator is a tool for generating XML messages from an existing XSD schema.
Using this tool, we can customize the desired message with additional fields or remove unnecessary elements from the message itself.
Another crucial part is that we can build a message for every child complex element in the schema with the desired number of optional and repeating fields.
Likewise, we are able to generate multiple complex elements from the same schema or different schema which we specify in the external Excel file.
For example, let’s assume that we need an example XML message from following XSD schema.
In this case, we have a complex type with the name “httpTransportHeaders” with several child elements and one element with a custom type named “Dynamic Headers”.
From this point of view, we need to define the element that is referencing the root complex element and populates the specific excel file accordingly:
After populating the desired fields, we are executing the .jar file and place the Excel file as an argument in the CLI.
In this case, you can notice that all of the fields are strings and they are filled with the name of their element, in cases where the element is numeric, it is filled with a random value.
As we have mentioned earlier we can generate test messages from multiple source destinations which we will explain in the next topic for SOAP messages.
This particular tool is intended for generating structured SOAP request messages from a WSDL file.
The pre-execution steps are almost the same as the previous tool with one minor exception – instead of the complex element we are specifying the desired operation from the WSDL file.
For this tool, we have a different excel file where the wsdlOperation is replacing the rootElement.
Let’s take Calculator.wsdl for example which contains four separate operations Add, Subtract, Multiply and Divide. http://www.dneonline.com/calculator.asmx?wsdl
Hence, we are populating the desired fields in our Excel file:
And execute the .jar file with the excel file as a parameter.
After this, we are ready to invoke the particular Soap service.
In addition, from the previous topic, we are using this tool for advanced testing purposes where the same generated Soap request messages are wrapped like SoapUI-project-XML file where we just need to import the project into the SoapUI open source and execute the unit tests.
Another advantage is that we are setting an additional Excel file named GlobalProperties.xlsx in order to customize global properties for the URL of the service for example:
And after the execution, these particular properties are automatically added and set into a Soap UI project.
Hence, we are populating the same fields as in the previous tool for generating Soap request messages with special emphasis on “type” column where we are determining how we want our Test Suite and Test Cases to be named.
After populating all fields, we are executing the .jar file with additional GlobalProperties file and another integer parameter where we are choosing a number of test cases.
Finally, we have our SoapUI-project.xml file and we can import into SoapUI tool with initialized global properties for the URL and ready-to-send messages in each Test Suite:
We have created this tool in order to generate HTTP client in SoapUI with certain variations.
In this case, we have only one Excel file named GlobalPropertiex.xlsx where instead of populating the fields regarding the structure of the message, we are filling the rows for URL like in the previous tool for generating Soap Requests, unlimited number and variations of query parameters and additional security configurations for TrustStore or KeyStore according to the option specified in the Store type column.
Alongside with the Global properties, we are executing traditional Java command:
And our SoapUI project is complete and we can invoke desired services.
- All of these tools have significantly improved the quality of work between developers.
- Development and unit testing processes are simplified with only a few configuration setups and one execution command.
- Reduced time-consuming during the Software Life Cycle
- Increased productivity in order to deliver reliable and seamless software.
- Manually executing each .jar individually with its own Excel file which can be tedious work.
Even though we manage to automate the unit testing with a few steps, we are certainly aware that there is still room for improvement in some of the productivity tools.
For example, instead of executing the command from the CLI and setting configuration from the Excel file, we can build interactive GUI and manipulate the values from dynamic fields or optional drop-downs for a better view.
From this point of view, all these tools are on track and are continuously used by our group of developers and have helped us considerably during building software packages for our clients.
As a Tibco team at ⋮IW we are always trying to automate every step of our development journey and improve our capabilities by building various bundle tools for unit testing, building code, and simulating services.