Testing Integration Flows

Testing integration flows means testing that data moves in accordance with the business requirements and that all components used in the flow operate together correctly.

When testing an integration flow, you should assume that each individual component will operate according to its documented behavior. Trying to write tests that validate component behavior and flow behavior will obfuscate results. See Testing Components for details on testing to verify behavior of components.

There are three types of testing that can be performed to validate integration flows: unit tests, integration tests, and end-to-end tests.

Unit Tests (JSONata and JavaScript)

Integration flows necessarily represent a series of different events occurring across multiple components. Therefore, testing a flow is by nature not a unit test. However, there are two configuration areas used in flows that represent business value, are not foundational component functionality, and can be unit tested: JSONata expressions and JavaScript snippets.

Unit Testing JSONata Expressions

JSONata expressions are used throughout any flow and virtually all components support the use of JSONata for at least some configuration fields. Most notably, the primary data transformation operation in a flow (e.g. converting orders from Shopify to STORD Orion orders) occurs in the JSONata transform component.

These JSONata expressions typically house most or all of the business logic that impacts the functionality of the flow. This also often includes parameterized inputs to be provided by the end user to manipulate how the integration works without having to write a custom flow.

Tests can be written in Mocha to mock input data, process that input data, and assert business rules and other logic on the output data. You may also use JSON schema to assert the structure of the output data is correct, if you have accurate schemas available.

Unit Testing JavaScript Snippets

Some flows will include the Code Component which runs a simple JavaScript function. This means the configuration that is provided to the component to tell it how to operate in the context of a business requirement is itself code. This code should also be unit tested using a framework like Mocha.

Integration Tests

Integration testing a flow validates that the series of components defined and configured in the flow work together to correctly deliver a business requirement. This likely requires multiple tests to validate multiple different “paths” an execution of a flow can take. It also assumes the components themselves are testing and functioning properly.

Integration tests require flows to be triggered using controlled, mock data and that the data on the other is asserted against various business requirements. These test can be run manually or automatically, but often running them manually is an effective place to start.

Integration tests should also validate that authentication functions work properly.

Additionally, the Flow Repository API validates any flows against the flow JSON schema. While this doesn’t necessarily validate in the context of a business requirement, it does help to ensure a flow is set up with the proper data structure.

End-to-End Tests

Like integration tests, end-to-end tests validate that the entire series of configured components does what it’s supposed to do. The difference is that with an end-to-end test you actually trigger and validate the integration flow using the external systems.

End-to-end tests can be more representative of real life, as long as they are set up properly. These tests tend to be brittle, because there is much out of the control of the tester (e.g. a third party system outage). The ability to execute these tests also depends on the availability of third party endpoint sandbox systems.

End-to-end tests are often run manually as part of the development process, however they could be automated using a framework like Cypress.