For Users of TEN framework
Standalone Testing of Extension
The TEN framework provides an independent extension testing mechanism. This mechanism allows developers to test extensions without relying on other TEN concepts, such as other TEN extensions, TEN graphs, or TEN apps. When developers need to test the behavior of an extension without running the entire TEN app, this independent extension testing mechanism is especially useful.
The standalone testing framework for TEN extensions follows two key principles:
Compatibility with any native testing framework of the used language.
For example, if a TEN extension is developed using C++, the Google gtest/gmock testing framework can be used alongside the TEN extension standalone testing framework to achieve independent testing of the C++ TEN extension.
Users don't need to modify any code in the extension under test.
The exact same extension code used in runtime can be fully tested using this standalone testing framework.
The standalone testing flow for extensions developed in different languages follows the same design principles and usage methods.
This ensures that once you learn the standalone testing concepts and methods for one language, you can quickly grasp the standalone testing concepts and methods for TEN extensions in other languages.
For users, the TEN extension standalone testing framework introduces two main concepts:
extension_tester
ten_env_tester
The role of extension_tester is similar to a testing driver, responsible for setting up and executing the entire testing process. ten_env_tester, on the other hand, behaves like a typical TEN extension's ten_env
instance, enabling users to invoke functionalities within the standalone testing framework from the callback of extension_tester
, such as sending messages to the extension under test and receiving messages from the extension.
From the API design of extension_tester and ten_env_tester, you can see that they are very similar to TEN extension and ten_env, and this is by design. The main purpose is to allow users familiar with extension development to quickly get accustomed to the standalone testing framework and then develop standalone test cases for the extension itself.
However, for testing purposes, there are inevitably APIs and features dedicated specifically to testing. To prevent these test-specific functionalities and APIs, which are not needed during actual runtime, from polluting the runtime API set, the standalone testing framework is designed not to directly use or extend the API sets of extension and ten_env. Instead, it introduces types and API sets that are exclusive to standalone testing. This separation ensures that the types and API sets used in actual runtime and those used during testing do not interfere with each other, avoiding any negative side effects.
Standalone Testing Framework Internal
Internally, the TEN extension standalone testing framework implicitly starts a test app, loads the extension addon to be tested (let’s call it extension A), and initializes a graph containing both the extension A to be tested and another extension (let’s call it extension B) dedicated to testing other extensions. All input and output messages of extension A are redirected to extension B, allowing users to customize inputs and outputs during the testing process and complete the actual testing work.
Basically, you can think of this testing extension hidden within the testing framework as a proxy between the extension being tested and the tester. It acts as a proxy extension within the TEN graph, facilitating the exchange of messages between the tested extension and the tester using the language of the TEN environment.
Basic Testing Process
The basic testing process and logic are as follows:
Create an extension tester to manage the entire standalone testing process.
Inform the standalone testing framework of the folder containing the extension to be tested.
Set a testing mode, such as a mode for testing a single extension.
Start the testing.
C++
Here is an example of TEN extension standalone testing using Google gtest:
Golang
TODO: To be added.
Python
Last updated