Manejo de opciones en Tradefed

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

El manejo de opciones es el núcleo del enfoque modular de Trade Federation. En particular, las opciones son el mecanismo a través del cual el desarrollador, el integrador y el ejecutor de pruebas pueden trabajar juntos sin tener que duplicar el trabajo de los demás. En pocas palabras, nuestra implementación del control de opciones permite al desarrollador marcar un miembro de clase de Java como configurable, en cuyo punto el integrador puede aumentar o anular el valor de ese miembro, y el ejecutor de pruebas puede aumentarlo o anularlo posteriormente. Este mecanismo funciona para todos los tipos intrínsecos de Java, así como para cualquier instancia de Map o Collection de tipos intrínsecos.

Nota: El mecanismo de control de opciones solo funciona para las clases que implementan una de las interfaces incluidas en el ciclo de vida de prueba y solo cuando el mecanismo de ciclo de vida crea una instancia de esa clase.

Desarrollador

Para comenzar, el desarrollador marca un miembro con la anotación @Option. Especifican (como mínimo) los valores name y description, que especifican el nombre del argumento asociado con esa opción y la descripción que se muestra en la consola de TF cuando se ejecuta el comando con --help o --help-all.

A modo de ejemplo, supongamos que queremos crear una prueba telefónica funcional que marque una variedad de números de teléfono y espere recibir una secuencia de tonos DTMF de cada número después de que se conecte.

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
    }

Eso es todo lo que se requiere para que el desarrollador configure dos puntos de configuración para esa prueba. Luego, podrían usar mWaitTime y mCalls como de costumbre, sin prestar mucha atención al hecho de que son configurables. Debido a que los campos @Option se establecen después de que se crea una instancia de la clase, pero antes de que se llame al método run, esto proporciona una forma fácil para que los implementadores configuren valores predeterminados o realicen algún tipo de filtrado en los campos Map y Collection, que de otro modo solo se pueden agregar.

Empresa integradora

El integrador trabaja en el mundo de las configuraciones, que se escriben en XML. El formato de configuración permite que el integrador establezca (o adjunte) un valor para cualquier campo @Option. Por ejemplo, supongamos que el integrador desea definir una prueba de latencia más baja que llame al número predeterminado, así como una prueba de larga duración que llame a una variedad de números. Podrían crear un par de configuraciones que podrían verse de la siguiente manera:

<?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>

Ejecutor de pruebas

Test Runner también tiene acceso a estos puntos de configuración a través de la consola de Trade Federation. En primer lugar, ejecutan un comando (es decir, una configuración y todos sus argumentos) con la instrucción run command <name> (o run <name>, en abreviatura). Además, pueden especificar cualquier lista de argumentos que forman parte del comando, que puede reemplazar o adjuntar a los campos especificados por los objetos de ciclo de vida dentro de cada configuración.

Para ejecutar la prueba de baja latencia con los números de teléfono many-numbers, el Test Runner podría ejecutar lo siguiente:

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

O bien, para obtener un efecto similar desde la dirección opuesta, el ejecutor de pruebas podría reducir el tiempo de espera de la prueba many-numbers:

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

Orden de las opciones

Es posible que notes que la implementación subyacente de la opción call es un Map, por lo que, cuando se repite --call en la línea de comandos, se almacenan todos.

La opción timeout, que tiene una implementación subyacente de long, solo puede almacenar un valor. Por lo tanto, solo se almacena el último valor especificado. --timeout 5 --timeout 10 genera timeout que contiene 10.

En el caso de List o Collection como la implementación subyacente, todos los valores se almacenan en el orden especificado en la línea de comandos.

Opciones booleanas

Las opciones de tipo subyacente booleano se pueden establecer en true pasando directamente el nombre de la opción, por ejemplo, --[option-name], y se pueden establecer en false con la sintaxis --no-[option-name].

Consulta también