Purpose
IBM App Connect Enterprise facilitates test-driven development of solutions through its test framework. You can use integration tests to check whether your integration flows operate as expected after development changes, upgrades, or changes to services that your flow interacts with. It also enables you to check whether changes to external services have impacted the operation of your flows. By using integration test capability as part of your test-driven development, you can develop and run unit tests more rapidly as part of a pipeline, without the need for third-party tools. Tests can be written for individual message flow nodes or for a subflow or a sequence of nodes or for the entire message flow itself. This controls the level of granularity in your testing and enables you to write tests that adapt to your specific needs to validate the functionality of your components.
The tests that you use to validate the message flows and nodes are written in Java and are stored in App Connect Enterprise test projects. A test project is a first class artifact that is available in version 12 of IBM App Connect Enterprise. It contains the class files as well as the resource files required for the tests to run. Its structure makes it compatible to use with Gradle or Maven easily. When we run a test project as an “Integration Sever JUnit” test or by simply clicking on the test project and selecting “Run Test Project”, the ACE Toolkit by default always uses a temporary working directory for hosting the Integration Server that actually runs the tests. This temporary directory is cleaned before each cycle of testing which may not be desirable in situations wherein configuration changes made to the YAML files are needed to be persisted. The purpose of this Blog is to demonstrate how the changes to the Integration Server used for JUnit testing can be made permanent using a specified existing work directory.
Prereqs
The Integration Test functionality exists with IBM App Connect Enterprise version 12
Configuration Steps for JUnit Testing
We’ll be using a Sample HTTP Echo Application that takes XML input in the format “<Name>Jane</Name>” and returns a Greeting message “{"Greetings":"Hi Jane”}”
Assuming we have Flow Exerciser enabled and the above message provided as Input to the flow, we can create an integration test for the Compute Node by just right clicking on the Compute Node and selecting “Create Test Case…” option.
The “Create test case” wizard will open, allowing selection of matchers and components to be selected for comparison. App Connect Enterprise allows interaction with third-party matcher libraries. Support is provided for JUnit assertions and third-party matcher libraries such as Hamcrest, JSONAssert, and XMLUnit as well as matchers for the App Connect Enterprise message assembly.
Make necessary modifications and click on Finish. The generated test project shall be visible in the Application Development view of the Toolkit. If we now right click on the test project and select “Run Test Project”, a new Integration Server will be created in the %temp% directory on Windows and /tmp/ directory on Linux. If we set any configurations in the server.conf.yaml file of the Integration Server, those changes will be reverted the next time the Project is executed. In order to make the changes to the Integration Server persist, we can create a Run Configuration for the test project via the Run option in the Toolkit Menubar.
This opens the “Run Configurations” wizard where we can select the test project based on whether we want to run a specific Test or all the tests inside of a project and select ok
We should also specify how to run the JUnit test as. For this, we can go to the Test tab and select “JUnit 5” as the “Test runner”.
In the Integration Server Settings tab, we need to check the option to use an existing work directory. This shall allow the test project to use the specified directory instead of creating a temporary one. This same work directory can later be reused for subsequent runs of the test project.
Run Configuration can then be applied and the Project can be executed as an Integration Server JUnit test. The changes to configuration for the specified work directory will be persisted across different runs of the test project. This also allows the use of mqsisetdbparms to set credentials for a resource associated with that work directory.
In addition to the above method, we can also use the command line option to run an Integration Server JUnit Test for the above scenario by manually specifying an Integration Server work directory. e.g.
IntegrationServer --work-dir IS1 --test-project HTTPEcho_Test --start-msgflows false
For the above to work, both the Application and the Test Project needs to be deployed to the specified Integration Server work directory. The procedure for this is already detailed in the App Connect Documentation (https://www.ibm.com/docs/en/app-connect/12.0?topic=dit-generating-tests-from-recorded-messages-in-message-flow)