O tratamento de opções está no centro da abordagem modular da Trade Federation. Especificamente, as opções
são o mecanismo pelo qual o desenvolvedor, o integrador e o executor de testes podem trabalhar juntos sem
ter que duplicar o trabalho uns dos outros. Simplificando, nossa implementação de manipulação de opções permite que
O desenvolvedor marca um membro de classe Java como configurável. A partir de então, o valor desse membro
pode ser aumentado ou substituído pelo integrador e pode ser subsequentemente aumentado ou substituído por
o executor de testes. 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 processamento de opções só funciona para classes que implementam um dos incluídas no ciclo de vida de testes e somente quando essa classe for instanciada pela máquina do ciclo de vida.
Desenvolvedor
Para começar, o desenvolvedor marca um membro com o
@Option
.
Elas especificam (no mínimo) os valores name
e description
, que
especificar o nome do argumento associado a essa opção e a descrição que será exibida no
no console do TF quando o comando for executado com --help
ou --help-all
.
Como exemplo, vamos criar um teste de telefone funcional que ligue para vários números de telefone, e espera receber uma sequência de toques DTMF de cada número depois dele 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 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 funciona no mundo de configurações, que são escritas em XML. 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 um teste de longa duração que chama vários números. Ela pode criar um par de configurações
que pode 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 testes
O Test Runner também tem acesso a esses pontos de configuração pelo console da Trade Federation.
Antes de mais nada, eles vão executar um comando (ou seja, uma configuração e todos os argumentos) com o
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 conseguir 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 de opções
A opção call
subjacente à implementação é um Map
Portanto, após --call
repetido 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 a implementação,
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
transmitindo diretamente o
nome da opção, por exemplo, --[option-name]
e pode ser definido como false
usando
a sintaxe --no-[option-name]
.