O manuseio de opções está no centro da abordagem modular da Federação do Comércio. Em particular, as opções são o mecanismo pelo qual o Desenvolvedor, Integrador e Executor de Testes podem trabalhar juntos sem ter que duplicar o trabalho um do outro. Simplificando, nossa implementação de manipulação de opções permite que o Desenvolvedor marque um membro de classe Java como sendo configurável, ponto em que o valor desse membro pode ser aumentado ou substituído pelo Integrador e pode ser posteriormente aumentado ou substituído pelo Test Runner. Esse mecanismo funciona para todos os tipos intrínsecos do Java, bem como para qualquer Map s ou Collection s de tipos intrínsecos.
Observação: o mecanismo de manipulação de opções funciona apenas para classes que implementam uma das interfaces incluídas no Test Lifecycle e somente quando essa classe é instanciada pelo mecanismo 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 de name e description , que especificam o nome do argumento associado a essa Opção e a descrição que será exibida no console do 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 que o Desenvolvedor configure dois pontos de configuração para esse teste. Eles poderiam então 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 configurarem 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 queira definir um teste de latência mais baixa 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 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 da 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 abreviar). Além disso, eles podem especificar que qualquer lista de argumentos faz parte do comando, que pode substituir ou anexar a campos especificados por Lifecycle Objects dentro de cada configuração.
Para executar o teste de baixa latência com os números de telefone 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 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
Pedido de opção
Você pode notar que a implementação subjacente da opção de call é um Map , então, após repetido --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. Assim, apenas o último valor especificado será armazenado. --timeout 5 --timeout 10 resultará em 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] .