Take our usability survey to improve this site.

User Parameters

In the Android Comms Test Suite (ACTS), additional test information or parameters can be specified from within the ACTS config. User params can be in any JSON-compliant format, and are decoded into the appropriate type in Python (for example, dict, list, and str). There are two places where user parameters can be specified:

  • At the root level of the config

    {
        "testbed": {
            ...
        },
        "my_user_param1": "my_value",
        "my_user_param2": {"another": ["value"]}
    }
    
  • Within a testbed

    {
        "testbed": {
            "my_testbed": {
                "AndroidDevice": [...],
                ...,
                "my_user_param1": "my_value",
                "my_user_param2": {"another": ["value"]}
            }
        },
    }
    

If a user parameter is found within the root level and within the testbed, the testbed-specific value is used.

In an ACTS test class, users can read this information using the following:

class MyActsTest
    def setup_class(self):
        self.my_param_1 = self.user_params['my_user_param1']

        # Get the parameter with a default value if not found within config.
        self.my_param_2 = self.user_params.get('my_user_param2', default={})

Special user parameters

Below is a list of useful optional user parameters that have special properties in ACTS:

  • consecutive_failure_limit: Number of consecutive test failures to allow before blocking remaining tests in the same test class. If not specified, the default behavior is to run all tests, regardless of failures. This parameter is useful in cases where the testbed is improperly configured, causing all tests to fail.

  • quiet_tests: List of test classes or test cases specified with the format test_class or test_class.test_name, for example, BleScanApiTest or BleScanApiTest.test_start_ble_scan_with_default_settings. Each test case in this list won't have any test failure artifacts generated (for example, bug reports, qxdm logs). If a test class name is specified without a test case, all test cases in the given class are set to skip bug reports. This flag can be used to suppress output for problematic test cases that are expected to fail.

  • retry_tests: List of test classes or test cases specified with the format test_class or test_class.test_name, for example, BleScanApiTest or BleScanApiTest.test_start_ble_scan_with_default_settings. For each test case in this list, if a test fails, it's retried once. If the test fails a second time, it's marked as a failure.