Parâmetros do usuário

No Pacote de testes de comunicação do Android (ACTS, na sigla em inglês), outras informações ou parâmetros de teste podem ser especificados na configuração do ACTS. Os parâmetros do usuário podem estar em qualquer formato compatível com JSON e são decodificados no tipo adequado em Python (por exemplo, dict, list e str). Há dois lugares em que os parâmetros do usuário podem ser especificados:

  • No nível raiz da configuração

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

  • Em um testbed

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

Se um parâmetro de usuário for encontrado no nível raiz e no testbed, o valor específico do testbed será usado.

Em uma classe de teste ACTS, os usuários podem ler essas informações usando o seguinte:

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={})

Parâmetros especiais de usuário

Veja uma lista de parâmetros de usuário opcionais úteis que têm propriedades especiais no ACTS:

  • consecutive_failure_limit: número de falhas de teste consecutivas a serem permitidas antes de bloquear os testes restantes na mesma classe de teste. Se não for especificado, o comportamento padrão será executar todos os testes, independentemente de falhas. Esse parâmetro é útil nos casos em que o testbed não está configurado incorretamente, fazendo com que todos os testes falhem.

  • quiet_tests: lista de classes ou casos de teste especificados com o formato test_class ou test_class.test_name, por exemplo, BleScanApiTest ou BleScanApiTest.test_start_ble_scan_with_default_settings. Cada caso de teste desta lista não terá nenhum artefato de falha de teste gerado (por exemplo, relatórios de bugs, registros qxdm). Se um nome de classe de teste for especificado sem um caso de teste, todos os casos na classe determinada serão configurados para pular relatórios de bugs. Essa sinalização pode ser usada para suprimir a saída para casos de teste problemáticos que podem falhar.

  • retry_tests: lista de classes ou casos de teste especificados com o formato test_class ou test_class.test_name, por exemplo, BleScanApiTest ou BleScanApiTest.test_start_ble_scan_with_default_settings. Para cada caso de teste nesta lista, se um teste falhar, ele será repetido uma vez. Se o teste falhar uma segunda vez, ele será marcado como uma falha.