Test-driven development is a concept in the software development practice, where software development is closely tracked by repeatedly executing tests. In its pure form tests must even exist before the software itself.
In this blog post, I’m going to show you step by step how Process Integration Test can bring you one step towards test-driven development while developing a new integration flow. Even if pure form of test-driven development can’t be reached with the current means available in PIT, the procedure will help you to achieve better quality through high test coverage and by avoiding mistakes at the very early stage in the development process.
Let’s assume I want to develop a new integration flow with complex routing conditions. To make sure, I formulated all conditions correctly and routing works as expected, I want to have a test message for each different condition path. As my integration flow is not yet productive, I do not have any sender who can send regular messages and though I can’t extract test messages into a test dataset in PIT.
Create an Integration Flow
I start at the very beginning in the Integration Designer perspective in NWDS and create a new integration flow, which has only one default, dummy receiver, and no conditions yet. I activate and deploy the integration flow.
Create a Test Case
Right afterwards, I can create a new PIT test case directly from the Integration Designer perspective. I select the integration flow, choose “Create Test Case” from context menu and follow the steps in the wizard. One prerequisite for the generation wizard is that a connection to the desired PIT system is maintained in the Process Integration Test perspective and a suitable test system entity already exists (crucial: the name of the test system in PIT must be equal to the system name in Integration Designer). I select the checkbox in the last wizard step for automatic switch to ‘SAP Process Integration Test’ perspective.
In the Process Integration Test perspective, the test case is added to the Test Catalog and the editor opens automatically. But instead of extracting message exchanges from the system into a test dataset (remember, there are no suitable messages in the system yet), I will create them manually using test data draft workbench. Later, I can create a test dataset containing these messages and assign it to the test case.
Create a Test Data Draft
With the help of the test data draft workbench, I can create many different test message exchanges for the integration flow and provide a suitable payload for each XPath condition and test the integration flow along the development process.
I open Test Data Draft Overview (in the NWDS perspective SAP Process Integration Test select menu Process Integration -> Test Data Draft Overview) and select “Create new test data draft” from the toolbar. I provide a name for the test data draft and assign my integration flow to it. Once the dialog is confirmed, the editor ‘Test Data Draft Workbench’ will open automatically.
In the test data draft workbench, I add my first message exchange draft manually using Add Message Exchange Draft -> Create New and insert my existing payload as content.
The new message exchange draft is shown in the list, its content is loaded and can be edited, if necessary.
In my aimed integration flow, the incoming message shall be mapped to different interfaces and go to different receivers dependent on the payload content. If no condition can be evaluated to true, an error message shall be generated. The first condition for the receiver REC_1_PRD looks like the following:
To cover all possible paths, I will need three different test message exchange drafts to test the first condition. Two message exchange drafts are for both ‘OR’ parts of the condition, which I expect to be processed successfully. The third message exchange draft does not match the condition and therefore shall result in an error.
I create additional message exchange drafts by copying my first message exchange draft (Add Message Exchange Draft -> New By Copy) and modify content of all three drafts according to my condition. I rename each message exchange draft, so that I can easier recognize which message covers which constellation.
Remember, as my dummy integration flow has no condition yet (see figure 1) all three message exchange drafts will succeed, when processing right away. However, this is not what I want to achieve.
Therefore, I go back to Integration Designer and modify my integration flow. I remove the dummy receiver, instead message shall go to the receiver REC_1_PRD. And I maintain the condition mentioned in the figure 8. In case no condition can be evaluated to true, message shall fail with error. I activate and deploy the changed integration flow.
Back in the Process Integration Test perspective, I process the three messages, which I prepared in the step before and get the result shown in figure 11. As expected, two messages are processed successfully and the third message fails with an error, as no receiver was found.
Create a Test Data Set
As next, I’m going to create two new test datasets ‘Path to PRD1 – success’ (containing successful messages) and ‘Path to PRD1 – error’ (containing error messages) for the first receiver REC_1_PRD using my messages. I decided to create two test datasets with only successful and only erroneous messages instead of one mixed test dataset (which is also possible), because later I would like to run a positive and a negative test.
The test datasets are added to the test case and can be used in run configurations.
Test Case Run Configuration
To be able to run a test in PIT, I need a run configuration. I create two run configurations – one for positive test and one for negative test using the above test data sets. In the negative test I would like not only to check, that the message fails but also that the message fails in the ROUTING step (‘Verify Error Expectation’ is checked).
I execute my run configurations and expect, that their execution will be successful. However, the first run for “Receiver PRD OK” fails due to differences in fields Id and employedSince, whose content is generated by mapping and will always differ between the runs. So, I must add exemptions to get the scenario successfully running.
I use the “Add Verification Exemption” wizard, which helps me to add a new exemption easily. It suggests me an XPath to be added based on the verification results. I finish the wizard and save the test case with the added exemption.
With the exemption, the positive test can be executed successfully.
Also, my negative test succeeds with the expected result (means, it fails with in error in ‘Routing’ step) as visible in the figure 17.
These run configurations can be executed after each iteration in the development process, e. g. when a new condition or a new receiver is added. But I can additionally collect all run configurations into one test suite and execute them comfortably on a scheduled base.
I create a new test suite and assign my test case to it. Test suites are visible in the Test Catalog, if ‘Test Suite’ is selected as top-level element.
As for test cases, PIT requires a ‘Test Suite Run Configuration’ as executable entity. It contains a set of test case run configurations. I assign my two available run configurations to the test suite run configuration.
Now, I can schedule my test suite run configuration for regular, e. g. daily execution. This will allow me a continuous monitoring of my development process and ensure that my changes do not have any side effects, which unintentionally damage other conditions. I also assign an alert configuration to the scheduled task, so that I’m notified in case of failures and thereby don’t need to check each execution manually.
The scheduled task is visible in the ‘Scheduled Tasks’ view (Window -> Show View -> Scheduled Tasks). From this view I can jump to the Action Log and display all its executions at one glance (context menu ‘Show Action Log’) as shown in Figure 21.
Luckily, my test runs still successfully also as a scheduled test suite run.
Thus, I can continue with my development and add more receiver, each with own condition. If I repeat below steps for each receiver and each condition, I will over time collect a nice list of suitable run configurations for each possible path. Executed after each iteration or on regular basis, it will allow me to recognize errors quickly, give me the confidence that the scenario is configured correctly and improve the quality.
In this blog post I described step by step how you can improve the development process of your PI scenario (using the example of Integration Flow development) using majority of the features available in SAP Process Integration Test. This procedure will help you to go one step towards test-driven development, to achieve high test coverage and to improve the quality of your develoment process.
Find more about PIT in SAP Help Portal and our blog posts in the “PIT – What’s new” series.