Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Escribir un corredor de pruebas de Tradefed

Esta página describe cómo escribir un nuevo corredor de prueba en Tradefed.

Fondo

Si tienes curiosidad sobre el lugar de los corredores de la prueba en la arquitectura Tradefed, consulte Estructura de un corredor de prueba .

Este no es un requisito previo para escribir un nuevo corredor de pruebas; los corredores de prueba se pueden escribir de forma aislada.

Mínimo básico: implementación de la interfaz

El mínimo para calificar como un corredor de prueba Tradefed es implementar la interfaz IRemoteTest y más específicamente el run(TestInformation testInfo, ITestInvocationListener listener) método.

Este método es el que invoca el arnés cuando se usa el ejecutor de pruebas, similar a un Java Runnable.

Cada parte de ese método se considera parte de la ejecución del corredor de pruebas.

Informar los resultados del corredor de pruebas

La run método en la interfaz base dan acceso a un objeto oyente de tipo ITestInvocationListener . Este objeto es la clave para informar resultados estructurados del corredor de prueba al arnés.

Al informar resultados estructurados, un corredor de pruebas 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 en algún otro estado.
  • Informe métricas asociadas con las pruebas si corresponde, por ejemplo métricas de tiempo de instalación.
  • Encaja en 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 rastro más granular de la ejecución.

Dicho esto, informar los resultados estructurados es opcional; un corredor de pruebas podría simplemente querer evaluar el estado de toda la ejecución como PASADA o FALLIDA 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 dados los beneficios enumerados anteriormente.

Se pueden invocar los siguientes eventos en el oyente para notificar al arnés del 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 aprobado.
    • testEnded: notifica el final del caso de prueba.
  • testRunFailed: notifica que el estado general del grupo de ejecución de casos de prueba es un error. Una prueba de funcionamiento puede ser un pase o una falla de forma independiente de los casos de prueba en función de los resultados de la ejecución de lo que esperaba. Por ejemplo, un binario correr varios casos de prueba podría reportar todos los casos de prueba pase pero con un código de salida de error (por cualquier razón: archivos filtrados, etc.).
  • testRunEnded: notifica el final del grupo de casos de prueba.

Mantener y asegurar el orden correcto de las devoluciones de llamada es responsabilidad del corredor ejecutor de prueba, por ejemplo, garantizando que testRunEnded se llama en caso de excepción utilizando un finally cláusula.

Los casos de prueba devoluciones de llamada ( testStarted , testEnded , etc.) son opcionales. Una ejecución de prueba puede ocurrir sin ningún caso de prueba.

Usted puede notar que esta estructura de eventos se inspira de la estructura típica de JUnit . Esto es a propósito para mantener las cosas cerca de algo básico sobre lo que los desarrolladores generalmente tienen conocimiento.

Informar registros del corredor de pruebas

Si va a escribir su propia clase de prueba Tradefed o corredor, usted implementará IRemoteTest y obtener una ITestInvocationListener a través del run() método. 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.

Escritores de prueba que quieren ir a la siguiente etapa de las pruebas del dispositivo tendrá las siguientes interfaces:

  • IDeviceTest permite recibir la ITestDevice objeto que representa el dispositivo bajo prueba y proporciona la API para interactuar con él.
  • IBuildReceiver permite la prueba para obtener el IBuildInfo objeto creado en el paso proveedor de generació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.

Prueba 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 un teléfono y un reloj.

Para escribir un corredor de prueba que se pueden utilizar varios dispositivos, tendrá que implementar el IMultiDeviceTest , lo que permitirá recibir un mapa de ITestDevice a IBuildInfo que contiene la lista completa de las representaciones del dispositivo y su información asociada de acumulación.

El colocador de la interfaz siempre se llamará antes de la run método, por lo que es seguro asumir que la estructura estará disponible cuando run se llama.

Pruebas conscientes de sus configuraciones.

NOTA: Este no es un caso de uso muy común. Está documentado para que esté completo, pero normalmente no lo necesitará.

Algunas implementaciones corredor de prueba puede ser que necesite información sobre la configuración global con el fin de funcionar correctamente, por ejemplo, algunos metadatos sobre la invocación o que target_preparer corriendo delante, etc.

Para lograr esto, un corredor de prueba puede acceder a la IConfiguration objeto es parte de y que se ejecuta en. Ver el objeto de configuración de descripción para más detalles.

Para la ejecución corredor de prueba, que tendrá que poner en práctica el IConfigurationReceiver para recibir el IConfiguration objeto.

Corredor de prueba flexible

Los corredores de pruebas pueden proporcionar una forma flexible de ejecutar sus pruebas si tienen un control granular sobre ellas, por ejemplo, un corredor de pruebas JUnit puede ejecutar individualmente cada prueba unitaria.

Esto permite que el arnés más grande y la infraestructura para el apalancamiento que el control fino y los usuarios ejecutar parcialmente el corredor de prueba a través de la filtración.

Soporte filtrante se describe en la interfaz ITestFilterReceiver , que permite recibir conjuntos de include y exclude filtros para las pruebas que se debe o no debe ejecutarse.

Nuestra convención es que se ejecutará una prueba si coincide con uno o más de los filtros de inclusión Y no coincide con ninguno de los filtros de exclusión. Si no se proporcionan filtros de inclusión, todas las pruebas deben ejecutarse siempre que no coincidan con ninguno de los filtros de exclusión.

NOTA: Alentamos a los corredores de prueba a escribir 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.