Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Manejo de opciones en Tradefed

El manejo de opciones se encuentra en el corazón del enfoque modular de Trade Federation. En particular, las opciones son el mecanismo por el 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 manejo de opciones permite al Desarrollador marcar un miembro de la clase Java como configurable, momento en el que el integrador puede aumentar o anular el valor de ese miembro y, posteriormente, el Ejecutor de pruebas puede aumentarlo o anularlo. Este mecanismo funciona para todos los tipos intrínsecos de Java, así como para cualquier Map o Collection de tipos intrínsecos.

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

Desarrollador

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

Como ejemplo, digamos que queremos crear una prueba de teléfono funcional que marcará una variedad de números de teléfono y esperará 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 necesita el desarrollador para establecer dos puntos de configuración para esa prueba. Luego podrían apagarse y 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 de run , eso proporciona una manera fácil para que los implementadores configuren los valores predeterminados o realicen algún tipo de filtrado en los campos Map y Collection , que de lo contrario se anexan. solamente.

Integrador

El Integrator trabaja en el mundo de las Configuraciones, que están escritas en XML. El formato de configuración permite al integrador establecer (o agregar) un valor para cualquier campo @Option . Por ejemplo, suponga que el integrador quisiera 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 como las siguientes:

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

Corredor 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, ejecutarán un comando (es decir, una configuración y todos sus argumentos) con la run command <name> (o run <name> para abreviar). Más allá de eso, pueden especificar cualquier lista de argumentos que forman parte del comando, que puede reemplazar o agregar a los campos especificados por Lifecycle Objects dentro de cada configuración.

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

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

O, para obtener un efecto similar en la dirección opuesta, Test Runner podría reducir el tiempo de espera para la prueba de many-numbers :

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

Pedido de opciones

Es posible que observe que la implementación subyacente de la opción de call es un Map por lo que, al repetir la --call en la línea de comando, todos se almacenarán.

El timeout opción, que tiene una implementación subyacente de long , solo puede almacenar un valor. Por lo tanto, solo se almacenará el último valor especificado. --timeout 5 --timeout 10 dará como resultado un timeout de timeout contiene 10.

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

Ver también

Pasar opciones a suite y módulos