Esta página describe cómo escribir un nuevo corredor de prueba en Tradefed.
Fondo
Si tiene curiosidad acerca del lugar que ocupan los corredores de prueba en la arquitectura de Tradefed, consulte Estructura de un corredor de prueba .
Este no es un requisito previo para escribir un nuevo corredor de prueba; los corredores de prueba se pueden escribir de forma aislada.
Mínimo: implementar la interfaz
Lo mínimo para calificar como corredor de pruebas de Tradefed es implementar la interfaz IRemoteTest y, más específicamente, el run(TestInformation testInfo, ITestInvocationListener listener) .
Este método es el que invoca el arnés cuando se usa el corredor de prueba, similar a Java Runnable.
Cada parte de ese método se considera parte de la ejecución del corredor de prueba.
Informe de resultados del corredor de pruebas
El método de run en la interfaz base da acceso a un objeto de escucha de tipo ITestInvocationListener . Este objeto es la clave para informar los resultados estructurados del corredor de pruebas al arnés.
Al informar resultados estructurados, un corredor de prueba tiene las siguientes propiedades:
- Informe una lista adecuada de todas las pruebas que se ejecutaron, cuánto tiempo tomaron y si pasaron individualmente, fallaron o algunos otros estados.
- Informe las métricas asociadas con las pruebas, si corresponde, por ejemplo, las métricas del tiempo de instalación.
- Se adapta a la mayoría de las herramientas de infraestructura, por ejemplo, mostrar resultados y métricas, etc.
- Por lo general, es más fácil de depurar ya que hay un seguimiento más granular de la ejecución.
Dicho esto, reportar resultados estructurados es opcional; un corredor de prueba podría simplemente querer evaluar el estado de toda la ejecución como APROBADO o FALLIDO sin ningún detalle de la ejecución real.
NOTA: Es más difícil implementar un corredor que siga la secuencia de eventos, pero recomendamos hacerlo debido a los beneficios enumerados anteriormente.
Se pueden invocar los siguientes eventos en el oyente para notificar al arnés el progreso actual de las ejecuciones:
- testRunStarted: Notifica el comienzo de un grupo de casos de prueba que están relacionados entre sí.
- testStarted: Notifica el inicio de un caso de prueba.
- testFailed/testIgnored: Notifica el cambio de estado del caso de prueba en curso. Un caso de prueba sin ningún cambio de estado se considera superado.
- testEnded: Notifica el final del caso de prueba.
- testRunFailed: notifica que el estado general de ejecución del grupo de casos de prueba es un error. Una ejecución de prueba puede ser un éxito o un error independientemente de los resultados de los casos de prueba, según lo que esperaba la ejecución. Por ejemplo, un binario que ejecuta varios casos de prueba podría informar todos los casos de prueba aprobados pero con un código de salida de error (por cualquier motivo: archivos filtrados, etc.).
- testRunEnded: Notifica el final del grupo de casos de prueba.
Mantener y garantizar el orden correcto de las devoluciones de llamada es responsabilidad del implementador del ejecutor de pruebas, por ejemplo, garantizar que se llame a testRunEnded en caso de excepción mediante una finally .
Las devoluciones de llamadas de casos de prueba ( testStarted , testEnded , etc.) son opcionales. Una ejecución de prueba puede ocurrir sin ningún caso de prueba.
Puede notar que esta estructura de eventos está inspirada en la estructura típica de JUnit . Esto tiene el propósito de mantener las cosas cerca de algo básico sobre lo que los desarrolladores generalmente tienen conocimiento.
Informes de registros del corredor de pruebas
Si está escribiendo su propio ejecutor o clase de prueba de Tradefed, implementará IRemoteTest y obtendrá un ITestInvocationListener a través del método run() . Este oyente se puede utilizar para registrar archivos de la siguiente manera:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Prueba con un dispositivo
La interfaz mínima anterior permite ejecutar pruebas muy simples que están aisladas y no requieren ningún recurso en particular, por ejemplo, pruebas unitarias de Java.
Los redactores de pruebas que deseen pasar al siguiente paso de las pruebas de dispositivos necesitarán las siguientes interfaces:
- IDeviceTest permite recibir el objeto
ITestDeviceque representa el dispositivo bajo prueba y proporciona la API para interactuar con él. - IBuildReceiver permite que la prueba obtenga el objeto
IBuildInfocreado en el paso del proveedor de compilación que contiene toda la información y los artefactos relacionados con la configuración de la prueba.
Los ejecutores de pruebas generalmente están interesados en estas interfaces para obtener artefactos relacionados con la ejecución, por ejemplo, archivos adicionales, y obtener el dispositivo bajo prueba que será el objetivo durante la ejecución.
Pruebas con varios dispositivos
Tradefed admite la ejecución de pruebas en varios dispositivos al mismo tiempo. Esto es útil cuando se prueban componentes que requieren una interacción externa, como el emparejamiento de un teléfono y un reloj.
Para escribir un ejecutor de pruebas que pueda usar varios dispositivos, deberá implementar IMultiDeviceTest , que permitirá recibir un mapa de ITestDevice a IBuildInfo que contiene la lista completa de representaciones de dispositivos y su información de compilación asociada.
El setter de la interfaz siempre se llamará antes que el método de run , por lo que es seguro asumir que la estructura estará disponible cuando se llame a la run .
Pruebas conscientes de sus configuraciones
NOTA: Este no es un caso de uso muy común. Está documentado para que esté completo, pero por lo general no lo necesitará.
Algunas implementaciones de corredores de prueba pueden necesitar información sobre la configuración general para funcionar correctamente, por ejemplo, algunos metadatos sobre la invocación, o qué target_preparer ejecutó antes, etc.
Para lograr esto, un ejecutor de pruebas puede acceder al objeto IConfiguration del que forma parte y en el que se ejecuta. Consulte la descripción del objeto de configuración para obtener más detalles.
Para la implementación del corredor de prueba, deberá implementar IConfigurationReceiver para recibir el objeto IConfiguration .
Corredor de pruebas flexible
Los ejecutores de pruebas pueden proporcionar una forma flexible de ejecutar sus pruebas si tienen un control granular sobre ellas, por ejemplo, un ejecutor de pruebas JUnit puede ejecutar individualmente cada prueba unitaria.
Esto permite que el arnés y la infraestructura más grandes aprovechen ese control preciso y que los usuarios ejecuten parcialmente el corredor de prueba a través del filtrado .
El soporte de filtrado se describe en la interfaz ITestFilterReceiver , que permite recibir conjuntos de filtros de include y exclude para las pruebas que deben o no ejecutarse.
Nuestra convención es que una prueba se ejecutará SIEMPRE que coincida con uno o más de los filtros de inclusión Y no coincida con ninguno de los filtros de exclusión. Si no se proporcionan filtros de inclusión, se deben ejecutar todas las pruebas siempre que no coincidan con ninguno de los filtros de exclusión.
NOTA: Alentamos a los ejecutores de pruebas a que se escriban de una manera que admita este filtrado, ya que proporciona un gran valor agregado en la infraestructura más grande. Pero entendemos que en algunos casos no es posible hacerlo.