How G7 IoT Platform Automates End‑to‑End Testing Across the Full Stack

Chapter 1: IoT Middleware Use‑Case and Template

The G7 IoT middleware integrates gateway access, event computing, and API services. Because the link is long and testing is opaque, use‑cases are organized flexibly across dimensions, as illustrated in the following diagram.

A typical IoT use‑case includes one input point and three verification points, covering two message‑queue topics and database validation.

Below is a template for a complete IoT use‑case.

Chapter 2: IoT Middleware Link Coverage and Automation Framework

The test cases must cover the entire chain: device → load balancer → gateway → message queue → real‑time computing → offline computing → database operations → result API query.

Automation support is described from four dimensions:

Gateway side: protocol parsing and response.

Event side: bulk data import and verification.

API side: API gateway and single‑node API chain coverage.

Full‑link side: abstract the whole link and provide corresponding automation APIs.

After two years of development, the overall G7 IoT automation framework looks like this:

Key features include:

Automation triggers via test platform, Jenkins, Ant, Maven.

Configurable workflow: custom variables, CI settings, case scope, report and email options.

Utility classes for message queues, keyword encapsulation, result comparison, NoSQL handling.

Case management with levels (smoke, main branch, sub‑branch) and selective execution.

Custom test reports using TestNG’s IReporter and ISuiteListener interfaces.

Chapter 3: Data Validation Approach and Examples

Typical event‑computing cases involve multiple data sets (expected vs. actual) with modest size, each containing 1…n records, resembling set operations available in mainstream languages. The framework provides common methods that integrate Kafka consumption and these operations.

Chapter 4: Structured Test Data & Keyword Encapsulation

Since TestNG does not provide a UI for writing cases or built‑in keywords, we implement our own. The interface automation offers protocol access and API validation templates.

Keyword encapsulation uses Java reflection: all user‑defined keyword methods are placed in a factory, and an invoker calls them dynamically.

Protocol access automation template:

TestNG’s @DataProvider loads data into test cases via the defined templates.

Chapter 5: Framework Thread Grouping and Data Isolation

TestNG supports parallel execution at test, class, and method levels. Configuration is done in

<suite name="TestngParallel Test" parallel="tests/classes/methods" thread-count="5">

. Tests level runs cases in the same thread; class level isolates per class; method level runs each @Test method in separate threads, similar to command‑pattern usage in Spring Cloud Hystrix.

Thread‑group strategy for IoT automated test cases is illustrated below:

Conclusion

The IoT automation testing solution plays a crucial role in G7’s full‑link testing, achieving over 80% coverage of main‑process business and delivering daily quality reports. It enables rapid releases without compromising quality, offering three main advantages: fast test case onboarding (one minute per case), broad component coverage (gateway, middleware, MySQL, Elasticsearch, etc.), and low entry cost thanks to encapsulated low‑code keywords.