Designing a Dynamic‑Proxy‑Based Interface Testing Framework for Transaction Order and Payment Systems

Designing a test framework requires aligning it with the system under test, avoiding over‑design, and ensuring the system provides sufficient testability.

The article focuses on a dynamic‑proxy‑based interface testing design and first introduces the two systems under test.

1. Transaction Order System

The order system is implemented as a state machine with forward and reverse flows. An example flow is shown below:

Orders are triggered by specific conditions, causing a transition from the current state to the next after pre‑validation.

The order context holds the current state and related information; operations update the context, persist changes, and handle UI rendering or messaging.

2. Payment Center Account System

This system does not have state transitions; operations directly modify account balances (e.g., recharge increases, withdrawal decreases).

Both systems share a common abstraction: an operation triggered under certain conditions causes a specific change in the subject (order status or account balance).

Early Test Case Implementation

Initially, many validation methods were written for different attributes (order status, button state, service window content, etc.). Each test case called the relevant validation methods with expected values. While readable, this approach suffered from:

Redundant validation calls across multiple test cases.

High maintenance cost when the system evolved, requiring updates to many scattered validation methods.

To address these issues, the article proposes intercepting operations, building pre‑ and post‑operation contexts, and letting a validation module use the context to perform checks.

Dynamic Proxy Overview

The UML diagram shows that both the proxy class and the real implementation inherit from an abstract subject class, ensuring method compatibility and transparent usage.

Implementation steps:

Define a Subject interface.

Implement the real subject class RealSubject .

Create a dynamic proxy class that implements InvocationHandler and overrides the invoke method.

Improved Test Case Structure

Each test case now works with a single context; multiple subjects are handled by maintaining multiple contexts and a switch‑based dispatcher.

Order system example: After an operation, update the order context, let the dynamic proxy trigger validation, and dispatch to specific validation methods based on the context.

Account system example: Initialize an account context on creation, update it on operations, and validate against the real system data.

Advantages

Validation logic is hidden from test cases, allowing writers to focus on operation steps.

Higher integration reduces maintenance; only validation modules need updates when the system changes.

Strong extensibility: new business variables can be added via new contexts and validation sub‑modules without rewriting existing cases.

Disadvantages

Increased design effort raises the entry barrier for writing test cases.

Framework and context knowledge are required for maintenance, adding a learning curve.

Dynamic Proxy in the Testing Framework

Two proxies are currently used:

SCF Proxy: intercepts SCF requests, collects parameters and responses for diffing, measures latency, and reports performance.

Validation Proxy: after an interface operation, updates various contexts (order, product, red packet, etc.) and triggers corresponding validations.

The overall idea is to intercept target class operations, add aspect logic, and extend the framework via plug‑in subsystems.

Summary

Design patterns serve as a foundation for building modular test systems. Future work includes designing an extensible settlement validation module to keep pace with rapid business growth.