O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Tratamento de opções em tradefed

O tratamento de opções está no cerne da abordagem modular da Trade Federation. Em particular, as opções são o mecanismo pelo qual o desenvolvedor, integrador e executor de teste podem trabalhar juntos sem ter que duplicar o trabalho um do outro. Simplificando, nossa implementação de manipulação de opções permite ao Desenvolvedor marcar um membro da classe Java como sendo configurável, ponto em que o valor desse membro pode ser aumentado ou substituído pelo Integrador e pode ser subsequentemente aumentado ou substituído pelo Test Runner. Esse mecanismo funciona para todos os tipos intrínsecos de Java, bem como para quaisquer Map ou Collection de tipos intrínsecos.

Nota: O mecanismo de tratamento de opções funciona apenas para classes que implementam uma das interfaces incluídas no Test Lifecycle e apenas quando essa classe é instanciada pelo maquinário de ciclo de vida.

Desenvolvedor

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

Como exemplo, digamos que queremos construir um teste de telefone funcional que discará uma variedade de números de telefone e esperará receber uma sequência de tons DTMF de cada número após a conexão.

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 é necessário para o desenvolvedor definir dois pontos de configuração para esse teste. Eles poderiam então desligar e usar mWaitTime e mCalls normalmente, sem prestar muita atenção ao fato de que eles 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 fornece 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 são anexados só.

Integrador

O Integrador trabalha no mundo das Configurações, que são escritas em XML. O formato de configuração permite que o Integrador defina (ou anexe) um valor para qualquer campo @Option . Por exemplo, suponha que o Integrador deseje definir um teste de latência inferior que liga para o número padrão, bem como um teste de longa duração que liga para uma variedade de números. Eles podem criar um par de configurações que podem se 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 teste

O Test Runner também tem acesso a esses pontos de configuração por meio do console Trade Federation. Em primeiro lugar, eles executarão um Comando (ou seja, uma configuração e todos os seus argumentos) com a instrução run command <name> (ou run <name> para breve). Além disso, eles podem especificar qualquer lista de argumentos que façam parte do comando, que pode substituir ou anexar a campos especificados por Lifecycle Objects em cada configuração.

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

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

Ou, para obter um efeito semelhante da direção oposta, o executor de teste pode reduzir o tempo de espera para o teste de many-numbers :

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

Pedido de opções

Você pode notar que a opção de call subjacente à implementação é um Map portanto, ao repetir --call 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 um timeout contendo 10.

No caso de uma List ou Collection como implementação subjacente, 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 passando 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

Opções de passagem para suíte e módulos