Update time: 0001-01-01

Quickly understand ACTS scripts

Do you have to frequently compile test cases? Are you frustrated by the following problems?

  • You have to repeat assertEquals, which is definitely not creative.
  • Missing an assert may lead to false success, while mistaking one may ruin your mood.
  • If the scenario is complex, the test code may be longer than the service code, which is painful.
  • You have to migrate utility classes every time you start writing test cases for a new application.

A TestNG test case is shown on the left side, and an ACTS test case on the right. Repeated coding is gone, and the code size is significantly reduced. Unlike ordinary test scripts, ACTS scripts inherit from the ActsTestBase class, which is encapsulated with data loading methods, driving methods, execution engines, and validation rules. Users do not have to clean or prepare data, run test cases, or validate results. ACTS implements zero coding for simple services, which greatly reduces the coding and maintenance costs.

TestNG vs ACTS

Generate test scripts

Prerequisites: Be sure to use Maven to compile your project and generate the object model. Otherwise, ACTS IDE may encounter unexpected errors, such as edit failures and incorrect data.

Right click a the method defined in the interface and select ACTS Function > Generate Test Case.

Generate test cases

Test script generation wizard

Automatic content generation

Run test script

Method: Right click the tested method in ACTS script, and select TestNG to run the test script as shown in the following figure.


Specify a test script to run

  1. Set test_only=^T in src/test/resource/config/ to run only the test case whose name starts with T. You can also replace ^T with other regular expressions.

  2. In this case, you can modify the name of the test case that you want to run by adding T in front of its name. ACTS only runs a test case whose name starts with T.

Modify the current use case name

Enter the test case name


Split test cases of the test script

ACTS stores all test case data of a test script in the same YAML file by default. You can determine whether to store test case data by test script or by test case by configuring the option spilt_yaml_by_case. It is set to false by default, which means all test case data of the same test script is stored in one YAML file.

You can set spilt_yaml_by_case=true in to store each test case of a new test script in a separate YAML file that is named after the case ID. This reduces the chances of file conflicts in the case where multiple developers work on the same interface.

In addition, ACTS provides a utility class that allows you split a legacy YAML file of a specified test script under a specified path by test case. See the following.


  • Note: Before the split, we recommend that you rename the original YAML file for backup, and then use the test case editor to check whether the content of the split files is correct. The original YAML file must be deleted if the split files are correct, because they cannot coexist.

Coding for data preparation

ACTS provides context APIs in the ActsRuntimeContext class for data preparation as follows:

  • Quickly get and set custom parameters:

Get all custom parameters: getParamMap getParamMap() Get custom parameters by key: Object getParamByName(String paraName) Add custom parameters: void addOneParam(String paraName, Object paraObj) Replace custom parameters: void setParamMap(Map<String, Object> paramMap) Get custom parameters by using a generic method: T getParamByNameWithGeneric(String paraName)

  • Quickly get and set test case request parameters

Get all request parameters: List getInputParams() Get request parameters by position: Object getInputParamByPos(int i) Add request parameters for the test case: void addInputParam(Object obj)

  • Quickly get and set response expectations

Get response expectations: Object getExpectResult() Set response expectations: Boolean setExpectResult(Object objToSet)

Use of the Mock function

The Mock function is currently based on the Mockito solution. For details, see the Mockito documentation in English or Mockito documentation in Chinese.

Add the dependency

Add the following dependency to the test module (skip this step if you have already introduced the test starter of SOFABoot)


By default, the Mockito version that Spring test depends on is 1.x. If you want to upgrade the version, exclude it first before you import the new version.


Mockito is used for stubbing during testing. You can use it to specify the value to be returned by a specific method of a class under a certain condition. The Mockito library enables object mocking, verification and stubbing. The sample code is as follows:

@SpringBootTest(classes = SOFABootApplication.class)
@TestExecutionListeners(listeners = MockitoTestExecutionListener.class)
public class RegisterUserActsTest extends ActsTestBase {

    // This is the test class
    public UserService userService;

    // This is the bean to be mocked
    public AccountManageFacadeClient accountManageFacadeClient;

    @Test(dataProvider = "ActsDataProvider")
    public void registerUser
                (String caseId, String desc, PrepareData prepareData) {
        runTest(caseId, prepareData);

    public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) {
        AccountManageResult accountManageResult = new AccountManageResult();
        accountManageResult.setOperateDt(new Date());

    public void setUserService(UserService userService) {
        this.userService = userService;