Processamento de opções no Tradefed

O processamento de opções está no centro da abordagem modular da Trade Federation. Em particular, as opções são o mecanismo pelo qual o desenvolvedor, o integrador e o executor de testes podem trabalhar juntos sem precisar duplicar o trabalho uns dos outros. Em outras palavras, nossa implementação do processamento de opções permite que o desenvolvedor marque um membro de classe Java como configurável. Assim, o valor desse membro pode ser aumentado ou substituído pelo integrador e, posteriormente, pelo TestRunner. Esse mecanismo funciona para todos os tipos intrínsecos do Java, bem como para qualquer instância Map ou Collection de tipos intrínsecos.

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

Desenvolvedor

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

Por exemplo, digamos que queremos criar um teste funcional de telefone que disca vários números de telefone e espera receber uma sequência de tons DTMF de cada número depois que ele 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 o que o desenvolvedor precisa para configurar dois pontos de configuração para esse teste. Depois, eles podem usar mWaitTime e mCalls normalmente, sem prestar muita atenção ao fato de que são configuráveis. Como os campos @Option são definidos depois que a classe é instanciada, mas antes que o método run seja chamado, isso oferece uma maneira fácil para os implementadores definirem padrões ou realizarem algum tipo de filtragem nos campos Map e Collection, que, de outra forma, seriam apenas de anexação.

Integradora

O integrador trabalha com configurações, que são escritas em XML. O formato de configuração permite que o integrador defina (ou adicione) um valor para qualquer campo @Option. Por exemplo, suponha que o integrador queira definir um teste de baixa latência que chame o número padrão, bem como um teste de longa duração que chame vários números. Eles podem criar um par de configurações que podem ser semelhantes a estas:

<?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>

Test Runner

O Test Runner também tem acesso a esses pontos de configuração pelo console do Trade Federation. Primeiro, eles executam um comando (ou seja, uma configuração e todos os argumentos dela) com a instrução run command <name> (ou run <name>, para abreviar). Além disso, eles podem especificar qualquer lista de argumentos que faz parte do comando, que pode substituir ou ser adicionada 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 pode executar:

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

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

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

Ordem das opções

Você pode notar que a implementação da opção call é um Map. Portanto, ao repetir --call na linha de comando, todos os comandos são armazenados.

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

No caso de uma List ou Collection como a implementação subjacente, todos os valores sã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 podem ser definidas como false usando a sintaxe --no-[option-name].

Veja também