O tratamento 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 Test Runner podem trabalhar juntos sem
duplicar o trabalho um do outro. Simplificando, nossa implementação de processamento de opções permite que o
desenvolvedor marque um membro de classe Java como configurável. Nesse ponto, o valor desse membro
pode ser aumentado ou substituído pelo integrador e, posteriormente, aumentado ou substituído pelo
Test Runner. 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 pelo mecanismo 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 name e description, que
especificam o nome do argumento associado a essa opção e a descrição exibida no
console do TF quando o comando é executado com --help ou --help-all.
Por exemplo, digamos que queremos criar um teste de telefone funcional que disque uma variedade de números de telefone e espere 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 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 trabalha no mundo das configurações, que são gravadas 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 quisesse definir um teste de menor latência que chame o número padrão, bem como
como um teste de longa duração que chama vários números. Eles podem criar um par de configurações
que pode ser semelhante a este:
<?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 da 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, 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 ter 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 das opções
A opção call da implementação é um Map.
Portanto, ao repetir --call na linha de comando, elas são armazenadas.
A opção timeout, que tem uma implementação subjacente de long,
só pode armazenar um valor. Portanto, 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,
todos os valores são armazenados na ordem especificada na linha de comando.
Opções booleanas
As opções do tipo booleano podem ser definidas como true transmitindo diretamente o
nome da opção, por exemplo, --[option-name]. Elas também podem ser definidas como false usando
a sintaxe --no-[option-name].