Mejores prácticas para la ejecución de entornos de pruebas personalizados

Confíe en el software gestionado por Device Farm y en las funciones de la API para ejecutar la configuración siempre que sea posible, en lugar de aplicar configuraciones similares mediante comandos de shell en el archivo de especificaciones de prueba. Esto incluye la configuración del host de prueba y del dispositivo, ya que será más sostenible y coherente en todos los hosts y dispositivos de prueba.

Si bien Device Farm lo alienta a personalizar el archivo de especificaciones de prueba tanto como necesite para ejecutar las pruebas, el archivo de especificaciones de prueba puede resultar difícil de mantener con el tiempo a medida que se le agreguen más comandos personalizados. Utilizar el software gestionado Device Farm (a través de herramientas como devicefarm-cli las herramientas predeterminadas disponibles en el$PATH) y utilizar funciones gestionadas (como el parámetro de deviceProxysolicitud) para simplificar el archivo de especificaciones de las pruebas al transferir la responsabilidad del mantenimiento al propio Device Farm.

No utilice rutas absolutas ni confíe en versiones secundarias específicas del archivo de especificaciones de prueba o del código del paquete de prueba. Device Farm aplica actualizaciones de rutina al host de prueba seleccionado y a las versiones de software incluidas. El uso de rutas específicas o absolutas (por ejemplo, /usr/local/bin/python en lugar depython) o la exigencia de versiones secundarias específicas (por ejemplo, Node.js 20.3.1 en lugar de solo 20) puede provocar que las pruebas no localicen el archivo o ejecutable requerido.

Como parte de la ejecución de las pruebas personalizadas, Device Farm configura varias variables de entorno y la $PATH variable para garantizar que las pruebas tengan una experiencia coherente en nuestros entornos dinámicos. Para obtener más información, consulte Variables de entorno para entornos de prueba personalizados y Software compatible en entornos de prueba personalizados.

Guarde los archivos generados o copiados en el directorio temporal durante la ejecución de la prueba. Hoy nos aseguramos de que el usuario pueda acceder al directorio temporal (/tmp) durante la ejecución de la prueba (además de los directorios gestionados, como el$DEVICEFARM_LOG_DIR). Otros directorios a los que el usuario tiene acceso pueden cambiar con el tiempo debido a las necesidades del servicio o del sistema operativo utilizado.

Guarde los registros de ejecución de las pruebas en $DEVICEFARM_LOG_DIR. Este es el directorio de artefactos predeterminado que se proporciona para que la ejecución añada registros de ejecución o artefactos. Cada uno de los ejemplos de especificaciones de prueba que proporcionamos utiliza este directorio para los artefactos de forma predeterminada.

Asegúrese de que sus comandos devuelvan un código distinto de cero en caso de error durante la test fase de la especificación de prueba. Determinamos si la ejecución ha fallado comprobando si hay un código de salida distinto de cero en cada comando de shell invocado durante la fase. test Debe asegurarse de que su estructura lógica o de prueba devuelva un código de salida distinto de cero para todos los escenarios deseados, que pueden requerir una configuración adicional.

Por ejemplo, algunos marcos de pruebas (por ejemplo JUnit5) no consideran que la ejecución de cero pruebas sea un error, lo que provocará que se detecte que las pruebas se han ejecutado correctamente aunque no se haya ejecutado nada. JUnit5 Como ejemplo, tendría que especificar la opción de línea de comandos --fail-if-no-tests para garantizar que este escenario se cierre con un código de salida distinto de cero.

Revise la compatibilidad del software con la versión del sistema operativo del dispositivo y la versión del host que utilizará para la ejecución de la prueba. Por ejemplo, hay ciertas características de los marcos de software de prueba (por ejemplo, Appium) que pueden no funcionar según lo previsto en todas las versiones del sistema operativo del dispositivo que se está probando.

Evite almacenar o registrar variables sensibles (como las claves de AWS) en el archivo de especificaciones de la prueba. Los archivos de especificaciones de prueba, los scripts generados por las especificaciones de prueba y los registros del script de especificaciones de prueba se proporcionan como elementos descargables al final de la ejecución de la prueba. Esto puede provocar que otros usuarios de tu cuenta que tengan acceso de lectura a la prueba revelen información secreta de forma no intencionada.