Bonnes pratiques pour l'exécution d'un environnement de test personnalisé - AWS Device Farm

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques pour l'exécution d'un environnement de test personnalisé

Les rubriques suivantes présentent les meilleures pratiques recommandées pour l'utilisation de l'exécution de tests personnalisés avec Device Farm.

Exécuter la configuration
  • Utilisez le logiciel géré par Device Farm et les fonctionnalités de l'API pour exécuter la configuration dans la mesure du possible, au lieu d'appliquer des configurations similaires via des commandes shell dans le fichier de spécifications de test. Cela inclut la configuration de l'hôte de test et du périphérique, car elle sera plus durable et cohérente entre les hôtes de test et les appareils.

    Device Farm vous encourage à personnaliser votre fichier de spécifications de test autant que nécessaire pour exécuter vos tests, mais le fichier de spécifications de test peut devenir difficile à gérer au fil du temps à mesure que des commandes plus personnalisées y sont ajoutées. Utilisation du logiciel géré par Device Farm (via des outils tels que devicefarm-cli les outils disponibles par défaut dans le$PATH) et utilisation de fonctionnalités gérées (telles que le paramètre de deviceProxydemande) pour simplifier le fichier de spécifications de test en transférant la responsabilité de la maintenance à Device Farm elle-même.

Spécifications de test et code du package de test
  • N'utilisez pas de chemins absolus et ne vous fiez pas à des versions mineures spécifiques dans votre fichier de spécifications de test ou le code de votre package de test. Device Farm applique des mises à jour de routine à l'hôte de test sélectionné et aux versions logicielles incluses. L'utilisation de chemins spécifiques ou absolus (par exemple /usr/local/bin/python au lieu depython) ou l'exigence de versions mineures spécifiques (par exemple Node.js 20.3.1 au lieu de simplement 20) peuvent empêcher vos tests de localiser le fichier exécutable/requis.

    Dans le cadre de l'exécution des tests personnalisés, Device Farm définit diverses variables d'environnement ainsi que la $PATH variable afin de garantir une expérience cohérente dans nos environnements dynamiques. Pour plus d’informations, consultez Variables d'environnement pour les environnements de test personnalisés et Logiciels pris en charge dans des environnements de test personnalisés.

  • Enregistrez les fichiers générés ou copiés dans le répertoire temporaire pendant le test. Aujourd'hui, nous nous assurons que le répertoire temporaire (/tmp) sera accessible à l'utilisateur pendant l'exécution du test (en plus des répertoires gérés, tels que le$DEVICEFARM_LOG_DIR). Les autres répertoires auxquels l'utilisateur a accès peuvent changer au fil du temps en fonction des besoins du service ou du système d'exploitation utilisé.

  • Enregistrez vos journaux d'exécution des tests dans $DEVICEFARM_LOG_DIR. Il s'agit du répertoire d'artefacts par défaut fourni à votre exécution pour y ajouter des journaux d'exécution ou des artefacts. Les exemples de spécifications de test que nous fournissons utilisent chacun ce répertoire pour les artefacts par défaut.

  • Assurez-vous que vos commandes renvoient un code différent de zéro en cas d'échec pendant la test phase de votre spécification de test. Nous déterminons si votre exécution a échoué en vérifiant la présence d'un code de sortie différent de zéro pour chaque commande shell invoquée pendant la test phase. Vous devez vous assurer que votre logique ou votre infrastructure de test renverra un code de sortie différent de zéro pour tous les scénarios souhaités, qui peuvent nécessiter une configuration supplémentaire.

    Par exemple, certains frameworks de test (tels que JUnit5) ne considèrent pas l'exécution d'un test comme un échec, ce qui entraînera la détection d'une exécution réussie de vos tests même si rien n'a été exécuté. À JUnit5 titre d'exemple, vous devez spécifier l'option de ligne de commande pour vous --fail-if-no-tests assurer que ce scénario se termine avec un code de sortie différent de zéro.

  • Vérifiez la compatibilité du logiciel avec la version du système d'exploitation de l'appareil et la version de l'hôte de test que vous utiliserez pour le test. Par exemple, certaines fonctionnalités des frameworks logiciels de test (par exemple : Appium) peuvent ne pas fonctionner comme prévu sur toutes les versions du système d'exploitation de l'appareil testé.

Sécurité
  • Évitez de stocker ou de consigner des variables sensibles (comme les clés AWS) dans votre fichier de spécifications de test. Les fichiers de spécifications de test, les scripts générés par les spécifications de test et les journaux des scripts de spécifications de test sont tous fournis sous forme d'artefacts téléchargeables à la fin de l'exécution du test. Cela peut entraîner la divulgation involontaire de secrets à d'autres utilisateurs de votre compte ayant un accès en lecture à votre test.