Frontend Interface Integration Testing Tool for JD.com

Frontend Interface Integration Testing Tool

Author Introduction

Huang Zhongping works in the iOS R&D team of JD.com’s merchant app, with years of iOS development experience and a background that includes work abroad and a stint in Palo Alto.

Background

During JD.com’s app development, frontend‑backend API integration is a critical bottleneck; mismatched understanding of the same API often slows down coordination. To address this, JD.com introduced an "API confirmation count" metric and shares practices that reduced this count.

Problems Faced

The main pain points in API integration were:

Difficulty self‑testing APIs because of numerous public parameters.

Low efficiency when testing complex features that require many inputs.

Lack of intuitive verification of whether an API is correctly deployed.

Solution

By analyzing the three problems, the team set concrete goals and worked backwards to design a solution.

Goals

Simulate public parameters to help backend developers validate APIs.

Provide a parameter‑copy feature to boost tester efficiency.

Optimize the testing workflow to raise self‑test pass rates and cut confirmation cycles.

Approach for "API Hard to Self‑Test"

Two objective reasons make server‑side APIs hard to self‑test: excessive public parameters (including time‑sensitive keys) and network‑environment dependencies.

The backend mainly needs frontend confirmation on two points: whether the API is correctly deployed and whether its output meets business requirements.

Improved Workflow

Scenario Simulation

Backend developers use the tool to verify that their API is properly deployed .

The tool validates the API output against the frontend’s interface specification.

Expected UI Design

To address the first scenario, the tool must simulate server‑side public parameters, which is feasible because the tool runs inside the app.

+ (NSMutableDictionary *)generateGatewayParams:(NSDictionary *)params
{
    NSMutableDictionary *gatewayHttpParams = [NSMutableDictionary dictionary];
    NSMutableDictionary *bodyParams = [NSMutableDictionary dictionary];
    // ... generate public parameters ...
    return gatewayHttpParams;
}

Creating public parameters

The tool UI is shown below:

The request shown ("{\"sc\":\"菜\"}") contains the private parameters for this API.

The "API Self‑Test" workflow proceeds as follows:

Select the target API.

The tool automatically displays the non‑public (private) parameters required.

Click "Request API" to simulate public parameters and send the request.

Compare the result JSON with the expected JSON and receive modification suggestions if mismatches exist.

Backend developers or testers can only use this tool in the pre‑release environment of the JD.com merchant app; it is hidden in production.

System Implementation

API Configuration: Interfaces are versioned via a configuration file containing fields such as "interface name", "expected JSON", and "parameter JSON". A file server is required for the frontend to fetch this configuration dynamically.

The configuration format includes a "functions" node listing the interfaces to be tested. Example of a single entry:

key: interface name;
expectJson: expected JSON output;
funcId: interface identifier;
params: private parameters (can be null or customized);

API Response Validation

The validation aims to give backend developers clear reasons and suggestions when an API returns errors. The core difficulty is recursively traversing the JSON tree, checking each key, value type, and providing feedback.

1. Simulate Request: Perform a network request, then display both the returned data and the expected JSON.

...
// Simulate network request
#pragma mark - JDHttpBaseApiDelegate
// Success callback
- (void)apiExecuteDidSuccess:(JDHttpBaseApi *)api{
    NSString *compareResult = [expectDict compareWithDict:api.resultData];
    // JSON structure comparison
    ...
}
// Failure callback
- (void)apiExecuteDidFailed:(JDHttpBaseApi *)api{
    ...handle request failure...
}

2. JSON Structure Comparison Algorithm

Implementation example:

- (NSString*)compareWithDict:(NSDictionary *)targetDict{
    NSString *res = @"";
    for (id key in self){ // iterate all keys in the expected dict
        NSObject *targetObj = [targetDict objectForKey:key];
        if (targetObj == nil )
            res = [NSString stringWithFormat:@"Expected key:%@ not found in result JSON; 
%@", key, res];
        else{
            NSObject *value = [self objectForKey:key]; // expected value
            // ... type checks, string checks, etc.
            if ([value isKindOfClass:[NSDictionary class]]){
                if ([targetObj isKindOfClass:[NSDictionary class]]){
                    NSString *subRes = [(NSDictionary *)value compareWithDict:(NSDictionary *)targetObj];
                    // ... accumulate sub‑results
                }
            }
        }
    }
    return res;
}

Improving Efficiency for Complex Feature Testing

For features like "Product Creation" that require over 20 parameters, QA previously spent more than two minutes entering them manually. The tool introduces a "parameter copy" feature that records the last request parameters for any monitored API, allowing testers to reuse and adjust them quickly.

Handling the Lack of Intuitive Verification

The tool validates the returned JSON against the expected JSON; any mismatches generate clear error messages, enabling backend developers to identify deployment or business‑logic issues without additional frontend confirmation.

Function[0000092] represents a server‑side error code indicating why the API output failed.

The "Result Comparison" view shows the differences between the actual and expected JSON, guiding the backend to redeploy or reconfigure the API as needed, thereby reducing communication cycles.

Conclusion

The tool solves three major pain points: it simulates public parameters to enable self‑testing, offers parameter copying to speed up complex feature testing, and provides automated response validation to eliminate manual verification. In practice, the average API confirmation count dropped from about 4.3 to 0.6, dramatically improving development efficiency.