Primero, asegúrese de comprender el manejo de opciones en Tradefed.
La configuración de la suite describe las dos capas que existen en la estructura de la suite:
- La suite de primer nivel
- los modulos
En un contexto Tradefed que no es una suite, no hay necesidad de pensar en ello; cada opción va a la invocación completa. En el contexto de una suite, los módulos se mantienen aislados de la suite; por lo que no todas las opciones están disponibles a su nivel.
Pasar opciones a la suite de nivel superior
La suite de nivel superior se comporta como la configuración Tradefed estándar: la configuración completa, incluido el ejecutor de la suite, recibe todas las opciones como una configuración Tradefed que no es la suite.
Pasar opciones a los módulos
Los módulos de forma predeterminada no reciben ninguna de las opciones pasadas al comando. Deben estar dirigidos explícitamente para recibir las opciones a través de la opción module-arg . Este aislamiento de las opciones de los módulos facilita la depuración.
Ejemplo:
cts-tradefed run cts --module-arg <module-name>:<option-name>:<option-value>
cts-tradefed run cts --module-arg CtsGestureTestCases:collect-tests-only:true
La sintaxis garantiza que el módulo de destino recibirá la opción dada.
Hay formas adicionales de pasar opciones a módulos como test-arg , que le permite pasar opciones al ejecutor de pruebas de cada módulo según el tipo o clase del ejecutor.
Ejemplo:
cts-tradefed run cts --test-arg <test-class>:<option-name>:<option-value>
cts-tradefed run cts --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
La sintaxis no se dirige a un módulo en particular, sino a todos los ejecutores de pruebas de una clase determinada. test-arg considera solo implementaciones de IRemoteTest como receptor potencial de las opciones.
Pasar opciones a una clase de prueba de Java en java_test_host
Si está agregando una @Option a su clase de prueba de Java como parte de un objetivo de compilación java_test_host, deberá usar lo siguiente para inyectar esa opción:
cts-tradefed run cts --module-arg <module-name>:set-option:<option-name>:<option-value>
set-option en este contexto es la opción del ejecutor HostTest del arnés de prueba que envuelve sus clases Java para ejecutarlas.
Si el destino de su archivo jar para las opciones contiene varias clases de prueba, de forma predeterminada, se espera que todas tengan la @opción especificada o usen la siguiente sintaxis para apuntar a una sola clase:
cts-tradefed run cts --module-arg <module-name>:set-option:<class-name>:<option-name>:<option-value>
Pasar filtros a la suite
Para filtrar algunas pruebas de un conjunto, utilizamos --include-filter y --exclude-filter para forzar la inclusión o exclusión de una prueba o módulo en particular, respectivamente. La exclusión tiene prioridad.
Usan este formato: [abi] <module-name> [test name]
Ejemplos:
--include-filter CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases android.gesture.cts.GestureTest#testGetStrokes
Primero, asegúrese de comprender el manejo de opciones en Tradefed.
La configuración de la suite describe las dos capas que existen en la estructura de la suite:
- La suite de primer nivel
- los modulos
En un contexto Tradefed que no es una suite, no hay necesidad de pensar en ello; cada opción va a la invocación completa. En el contexto de una suite, los módulos se mantienen aislados de la suite; por lo que no todas las opciones están disponibles a su nivel.
Pasar opciones a la suite de nivel superior
La suite de nivel superior se comporta como la configuración Tradefed estándar: la configuración completa, incluido el ejecutor de la suite, recibe todas las opciones como una configuración Tradefed que no es la suite.
Pasar opciones a los módulos
Los módulos de forma predeterminada no reciben ninguna de las opciones pasadas al comando. Deben estar dirigidos explícitamente para recibir las opciones a través de la opción module-arg . Este aislamiento de las opciones de los módulos facilita la depuración.
Ejemplo:
cts-tradefed run cts --module-arg <module-name>:<option-name>:<option-value>
cts-tradefed run cts --module-arg CtsGestureTestCases:collect-tests-only:true
La sintaxis garantiza que el módulo de destino recibirá la opción dada.
Hay formas adicionales de pasar opciones a módulos como test-arg , que le permite pasar opciones al ejecutor de pruebas de cada módulo según el tipo o clase del ejecutor.
Ejemplo:
cts-tradefed run cts --test-arg <test-class>:<option-name>:<option-value>
cts-tradefed run cts --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
La sintaxis no se dirige a un módulo en particular, sino a todos los ejecutores de pruebas de una clase determinada. test-arg considera solo implementaciones de IRemoteTest como receptor potencial de las opciones.
Pasar opciones a una clase de prueba de Java en java_test_host
Si está agregando una @Option a su clase de prueba de Java como parte de un objetivo de compilación java_test_host, deberá usar lo siguiente para inyectar esa opción:
cts-tradefed run cts --module-arg <module-name>:set-option:<option-name>:<option-value>
set-option en este contexto es la opción del ejecutor HostTest del arnés de prueba que envuelve sus clases Java para ejecutarlas.
Si el destino de su archivo jar para las opciones contiene varias clases de prueba, de forma predeterminada, se espera que todas tengan la @opción especificada o usen la siguiente sintaxis para apuntar a una sola clase:
cts-tradefed run cts --module-arg <module-name>:set-option:<class-name>:<option-name>:<option-value>
Pasar filtros a la suite
Para filtrar algunas pruebas de un conjunto, utilizamos --include-filter y --exclude-filter para forzar la inclusión o exclusión de una prueba o módulo en particular, respectivamente. La exclusión tiene prioridad.
Usan este formato: [abi] <module-name> [test name]
Ejemplos:
--include-filter CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases android.gesture.cts.GestureTest#testGetStrokes