O tratamento de opções está no cerne da abordagem modular da Federação do Comércio. 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 um do outro. Simplificando, nossa implementação de manipulação de opções permite que o Desenvolvedor marque um membro da classe Java como 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. Este mecanismo funciona para todos os tipos intrínsecos Java, bem como para quaisquer Map s ou Collection s 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 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 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 .
Por 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 estabeleça dois pontos de configuração para aquele teste. Eles poderiam então 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 após a classe ser instanciada, mas antes do método run ser chamado, isso fornece uma maneira fácil para os implementadores definirem padrões ou executarem algum tipo de filtragem nos campos Map e Collection , que de outra forma são anexados. apenas.
Integrador
O Integrador atua 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 menor latência que ligue para o número padrão, bem como um teste de longa duração que ligue para vários números. Eles poderiam criar um par de configurações parecidas com as seguintes:
<?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 qualquer lista de argumentos que fazem parte do comando, que pode substituir ou anexar campos especificados pelos Lifecycle Objects em cada configuração.
Para executar o teste de baixa latência com many-numbers de telefone, 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 poderia reduzir o tempo de espera para o teste many-numbers :
tf> run many-numbers.xml --timeout 5000
Pedido de opções
Você pode notar que a opção call subjacente à implementação é um Map , portanto, após repetida --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 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
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] .