Design and Implementation of the Lego API Automation Testing Platform

This article introduces the Lego platform, an internal API automation testing solution built with a Jenkins+TestNG+ReportNG stack and a custom Java base library.

Key characteristics of API automation are low investment, high output, ease of implementation, and higher stability compared with UI automation.

To achieve a good ROI, the author emphasizes reducing tool development cost, simplifying test case entry, and minimizing maintenance effort by reusing existing tools, batch‑generating test cases, and keeping test scripts lightweight.

Platform composition : the system consists of a web site (Servlet/JSP + Bootstrap), a MySQL database for data‑driven test cases, and Java test scripts executed by Jenkins. The web UI allows users to create, edit, copy, delete, and schedule test cases.

Script design follows the familiar Jenkins+TestNG pattern. Test data are provided by a DataProvider_forDB class that reads cases from MySQL. Example code:

public class TestPigeon { 
    String sql; 
    int team_id = -1; 
    @Parameters({"sql", "team_id"}) 
    @BeforeClass() 
    public void beforeClass(String sql, int team_id) { 
        this.sql = sql; 
        this.team_id = team_id; 
        ResultRecorder.cleanInfo(); 
    } 
    @DataProvider(name = "testData") 
    private Iterator<Object[]> getData() throws SQLException, ClassNotFoundException { 
        return new DataProvider_forDB(TestConfig.DB_IP, TestConfig.DB_PORT, 
            TestConfig.DB_BASE_NAME, TestConfig.DB_USERNAME, TestConfig.DB_PASSWORD, sql);
    } 
    @Test(dataProvider = "testData") 
    public void test(Map<String, String> data) { 
        new ExecPigeonTest().execTestCase(data, false);
    } 
    @AfterMethod 
    public void afterMethod(ITestResult result, Object[] objs) { ... } 
    @AfterClass 
    public void consoleLog() { ... } 
}

The DataProvider_forDB implementation is also provided:

public class DataProvider_forDB implements Iterator<Object[]> { 
    ResultSet rs; 
    ResultSetMetaData rd; 
    public DataProvider_forDB(String ip, String port, String baseName, 
        String userName, String password, String sql) throws ClassNotFoundException, SQLException { 
        Class.forName("com.mysql.jdbc.Driver"); 
        String url = String.format("jdbc:mysql://%s:%s/%s", ip, port, baseName); 
        Connection conn = DriverManager.getConnection(url, userName, password); 
        Statement createStatement = conn.createStatement(); 
        rs = createStatement.executeQuery(sql); 
        rd = rs.getMetaData(); 
    } 
    @Override public boolean hasNext() { ... } 
    @Override public Object[] next() { ... } 
    @Override public void remove() { ... } 
}

Configuration is defined in an XML suite file that specifies the SQL query selecting test cases, the target service, and listeners for ReportNG.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Pigeon Api测试" parallel="false">
    <test name="xxx-xxx-service">
        <parameter name="sql" value="SELECT * FROM API_PigeonCases WHERE team_id=2 AND isRun=1 AND service='xxx-xxx-service' AND env='beta';"/>
        <classes>
            <class name="com.dp.lego.test.TestPigeon"/>
        </classes>
    </test>
    <listeners>
        <listener class-name="org.uncommons.reportng.HTMLReporter"/>
        <listener class-name="org.uncommons.reportng.JUnitXMLReporter"/>
    </listeners>
</suite>

Parameterization separates test data from scripts. Values can be injected via ${var} placeholders, which are resolved from key‑value tables, SQL queries, or previous test case results. This reduces code changes when data evolve.

Pre‑ and post‑actions allow arbitrary operations before or after a request, such as executing SQL, calling another test case, sending MQ messages, performing HTTP calls, waiting, or invoking custom Java methods. The results of these actions can be referenced with ${pre.xxx} placeholders.

Reporting uses ReportNG to generate detailed HTML reports with color‑coded success/failure, and the platform can export results to the database for statistical dashboards (success rate trends, failure‑reason analysis, test case coverage, etc.).

Site development was done by a single engineer using Servlet/JSP, Bootstrap, JSTL, MySQL, and Docker. The web UI provides case maintenance, one‑click execution, and online debugging, while the backend scripts run independently.

Operations are automated via Jenkins pipelines that trigger nightly builds, collect results, and push metrics to monitoring dashboards. Jacoco integration enables code‑coverage analysis for the test code.

Overall, the Lego platform demonstrates a practical, data‑driven approach to API test automation that balances ease of use, maintainability, and extensibility.