Testing strategy of enterprise system integration point

Integration is a topic that cannot be bypassed in an enterprise application system. Integration points with external systems are not only difficult to implement, but also hard to test. This paper introduces a universally applicable integration point testing strategy, which takes into account the coverage, speed, reliability and repeatability of the test, and establishes a general reference for the realization and test of the integration point.

Background

The system described in this article as an example is a typical Java EE Web application, based on Java 6 and spring development, using MAVEN constructs. The system needs to integrate two external systems in the form of XML over HTTP.

The system is delivered by a typical distributed team: The business representative normally works in Melbourne and the delivery team is located in Sydney and Chengdu. As a technology leader, I lead a team in Chengdu to undertake the main delivery tasks.

Pain Point

Because of the need to integrate two external systems, part of our MAVEN build [1] process testing (using JUnit) is associated with integration. This part of the test caused some trouble to the build process.

The first is the reliability of dependent systems. Of the two services that are being relied upon, one instance of a service deployed in the development environment often shuts down maintenance, and once it shuts down, it causes the test that it integrates with it to fail, leading to the entire build failure. Our delivery team adheres strictly to continuous integration practices: Code is not allowed to be submitted when a build fails. In this way, when we rely on the service shutdown maintenance, the delivery team's normal working rhythm will be disrupted.

Even if there is no shutdown maintenance, as the service instances deployed in the development environment are constantly being tested and tuned, the service instances that are being relied on often run low performance and respond to a long time, making our build process slow and sometimes even random build failures.

The unreliable and low performance of the dependent services in the development environment will make the application's build process fragile and slow, thus hitting the programmer's enthusiasm for frequent construction and even compromising the effectiveness of continuous integration. As the technical leader of the team, I want to solve this problem and make the build run reliably and quickly to ensure that everyone is willing to perform the build frequently.

How to test integration points

In a spring based application, integration with external services is often encapsulated as a Java interface and several of its methods. For example, the service "Create a brand user" is likely to be rendered as follows:

Public interface 

Identityservice {
    
customer Create (Brand Brand, customer customer);

An object that implements the Identityservice interface is instantiated by spring and put into the application context, and the client code that needs to use the service can get a reference to the object by relying on injection to invoke its Create method. When testing these client code, you can always mock a identityservice object and inject it into the object being tested, thus decoupling the dependency on the external service. This is the benefit of using dependency injection.

Therefore, our problem is mainly focused on the testing of the integration point itself.

Integrating an HTTP based service in an object-oriented language, the design of integration points often comes up with five main components: façade (façade); Request Builder (Request Builder), requesting router (requests Router) ; Network endpoint (network end point); Answer parser (Response Parser). The interaction between them is the following diagram: