Designing an Extensible Test System for Microservice Transaction Platforms

Testing strategy must first understand business characteristics and pain points to design a reasonable plan that satisfies current requirements while supporting future growth and system refactoring.

In the early stage of a microservice system, services are still tightly coupled because business shapes are not fully formed. An "all‑in‑one" approach can quickly meet immediate needs and reduce maintenance cost, but it leads to monolithic test methods that become a bottleneck as the system scales.

Initially, test cases bundled client initialization, data setup, interface calls, and result verification into a single method, which allowed rapid response to requirements but produced redundant code and duplicated validation logic.

As the transaction system grew, services were split horizontally and vertically, exposing queuing problems when a single service was deployed. The original all‑in‑one test cases could no longer keep up with the increasing number of cases and duplicated code.

To address this, the test framework abstracted common actions into an ActionCollection module and centralized assertions into an Assert module. Test cases now only orchestrate actions and invoke the corresponding assertions, dramatically reducing redundancy and improving reuse.

With the addition of vertical business lines, maintaining separate transaction flows for each became costly. An aspect‑oriented design was introduced, creating two proxy layers: one at the operation level and another at the client (request) level. The operation proxy isolates validation logic, allowing test cases to focus solely on business operations while the proxy handles verification based on context.

The client proxy can provide utilities such as response diff tools, supporting refactoring‑related tests.

A state‑machine driven configuration mechanism locks the current state at an extension point, executes the extension, and hands over order rendering to a third‑party until the state is unlocked.

Business horizontal division clarifies system structure (business, promotion, transaction, payment, settlement layers) but introduces regression challenges: any change at the top or bottom layer can trigger extensive retesting.

To mitigate this, the testing system was refactored into an extensible architecture where a calculation layer sits above the validation layer, maintaining state transition data and formulas. This separation makes business‑level changes require only updates to the relevant formula, enabling full‑business regression with minimal effort.

After an operation executes, the context is packaged and the proxy triggers validation. If the operation impacts other contexts (e.g., order affecting coupons or products), those contexts are updated and their validations are re‑executed.

The final architecture consists of two proxy layers, an independent context maintenance module, and a separate validation module, providing a scalable and maintainable testing solution for complex microservice transaction systems.