Tratamento de opções no Tradefed

O tratamento de opções está no centro da abordagem modular da Trade Federation. Especificamente, as opções são o mecanismo pelo qual o desenvolvedor, o integrador e o executor de testes podem trabalhar juntos sem ter que duplicar o trabalho uns dos outros. Simplificando, nossa implementação de manipulação de opções permite que O desenvolvedor marca um membro de classe Java como configurável. A partir de então, o valor desse membro pode ser aumentado ou substituído pelo integrador e pode ser subsequentemente aumentado ou substituído por o executor de testes. Esse mecanismo funciona para todos os tipos intrínsecos do Java, bem como para qualquer Maps ou Collections de tipos intrínsecos.

Observação:o mecanismo de processamento de opções só funciona para classes que implementam um dos incluídas no ciclo de vida de testes e somente quando essa classe for instanciada pela máquina do ciclo de vida.

Desenvolvedor

Para começar, o desenvolvedor marca um membro com o @Option. Elas especificam (no mínimo) os valores name e description, que especificar o nome do argumento associado a essa opção e a descrição que será exibida no no console do TF quando o comando for executado com --help ou --help-all.

Como exemplo, vamos criar um teste de telefone funcional que ligue para vários números de telefone, e espera receber uma sequência de toques DTMF de cada número depois dele se conecta.

public class PhoneCallFuncTest extends IRemoteTest {
    @Option(name = "timeout", description = "How long to wait for connection, in millis")
    private long mWaitTime = 30 * 1000;  // 30 seconds

    @Option(name = "call", description = "Key: Phone number to attempt.  " +
            "Value: DTMF to expect.  May be repeated.")
    private Map<String, String> mCalls = new HashMap<String, String>;

    public PhoneCallFuncTest() {
        mCalls.add("123-456-7890", "01134");  // default
    }

Isso é tudo que é necessário para que o desenvolvedor defina dois pontos de configuração para isso. teste. Eles podem usar mWaitTime e mCalls normalmente, sem prestar atenção ao fato de que elas são configuráveis. Como o Os campos @Option são definidos depois que a classe é instanciada, mas antes da O método run é chamado, oferecendo uma maneira fácil para os implementadores definirem padrões para ou realizar algum tipo de filtragem nos campos Map e Collection, que são caso contrário, somente anexação.

Integradora

O integrador funciona no mundo de configurações, que são escritas em XML. Formato de configuração permite que o integrador defina (ou anexe) um valor para qualquer campo @Option. Por exemplo: suponha que o integrador quisesse definir um teste de menor latência que chame o número padrão, bem como um teste de longa duração que chama vários números. Ela pode criar um par de configurações que pode parecer com o seguinte:

<?xml version="1.0" encoding="utf-8"?>
<configuration description="low-latency default test; low-latency.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="timeout" value="5000" />
    </test>
</configuration>

<?xml version="1.0" encoding="utf-8"?>
<configuration description="call a bunch of numbers; many-numbers.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="call" key="111-111-1111" value="#*#*TEST1*#*#" />
        <option name="call" key="222-222-2222" value="#*#*TEST2*#*#" />
        <!-- ... -->
    </test>
</configuration>

Executor de testes

O Test Runner também tem acesso a esses pontos de configuração pelo console da Trade Federation. Antes de mais nada, eles vão executar um comando (ou seja, uma configuração e todos os argumentos) com o Instrução run command <name> (ou run <name> para abreviar). Além disso, podem especificar qualquer lista de argumentos que fazem parte do comando, que pode substituir ou anexar aos campos especificados por objetos de ciclo de vida em cada configuração.

Para executar o teste de baixa latência com os números de telefone many-numbers, o Test Runner poderia executar:

tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#

Ou, para conseguir um efeito semelhante na direção oposta, o Test Runner pode reduzir o tempo de espera para o teste many-numbers:

tf> run many-numbers.xml --timeout 5000

Ordem de opções

A opção call subjacente à implementação é um Map Portanto, após --call repetido na linha de comando, todos eles serão armazenados.

A opção timeout, que tem uma implementação subjacente de long, só pode armazenar um valor. Portanto, apenas o último valor especificado será armazenado. --timeout 5 --timeout 10 resultará em timeout contendo 10.

No caso de uma List ou Collection como a implementação, todos os valores serão armazenados na ordem especificada na linha de comando.

Opções booleanas

As opções do tipo booleano subjacente podem ser definidas como true transmitindo diretamente o nome da opção, por exemplo, --[option-name] e pode ser definido como false usando a sintaxe --no-[option-name].

Consulte também