Integration Tests
Unifi can create an automated Integration Test which will capture and replay the Transaction scenarios from an existing Bond.
Last updated
Unifi can create an automated Integration Test which will capture and replay the Transaction scenarios from an existing Bond.
Last updated
An Integration Test is the overarching automated test record and correlates to the Bond. At the click of a button, Unifi will generate an Integration Test directly from the Bond record. The test comprises each of the Integration Test Scenarios (which correlate to the Transactions on that Bond). This means you can create an automated test based on real-world data in your instance which can be re-used to test the functionality of the Unifi process.
Because tests are generated from real-world data in your instance, in order for your tests to work in other instances, the data that you use has to exist in those instances as well (i.e. the data contained on the bonded record e.g. Caller, Assignment group etc.).
Instead of repeating the same manual process each test cycle (i.e. manually running through different scenarios), using automated Integration Tests for the various scenarios means that future testing would reduce a task which may have taken several hours to a matter of seconds.
If you change your process (e.g. change the structure of data objects being exchanged), you will need to generate new tests.
The Unifi Admin [x_snd_eb.admin] role is required to generate Integration Tests.
For instructions on generating, running and exploring Integration Tests, see our Unifi Test Assistant Feature Guide.
These tests are used to check Unifi's processing of the data i.e. to compare whether it is behaving in the same manner and producing the same results when processing the generated test compared with processing the original records. It checks not only the data itself, but also the Unifi processes that trigger, transport and respond to that data moving through Unifi.
When running a test, no connection is made to the other system. Instead, Unifi calls a mock web service which responds with results from the original scenario. Unifi then tests what happens with that response. Doing this helps to ensure the accuracy of the test (testing the functionality of the Unifi process in your instance), without relying on input from an external instance (potentially adding further variables to the test).
In the current release, automated testing supports only REST and JSON payloads (not SOAP or XML). Automated testing of attachment messages is also not supported.
Whenever you package your Integration (for details, see the Packager Feature Guide), any Integration Tests you create will also be included along with the other elements of your packaged Integration.
The following table describes the fields which are visible on the Integration Test record.
Field | Type | Description |
Name* | String | The name of the Integration Test. Automatically populated from the Integration, Unifi version and the Bond used to generate the test. |
Integration | Reference | The Integration this test belongs to. |
Unifi version | String | The licensed version of Unifi at the time the test was created. |
Application | Reference | Application scope of the test. |
Created | Glide date time | The time the test was created. |
Active | Boolean | Set to true to use this test. |
Description | String | Use this to enter a meaningful description for your test e.g. Inbound asynchronous test, or Outbound synchronous test |
*Name: Though automatically populated, this value can be edited to suit.
The 'Integration Test Scenarios' and 'Integration Test Results' related lists are also visible on the Integration Test record.