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 tester les applications sans serveur

Les sections suivantes décrivent les bonnes pratiques pour obtenir une couverture efficace lors du test d'applications sans serveur.

Prioriser les tests dans le cloud

Pour des applications bien conçues, vous pouvez utiliser diverses techniques de test pour répondre à un éventail d'exigences et de conditions. Cependant, sur la base des outils actuels, nous vous recommandons de vous concentrer autant que possible sur les tests dans le cloud. Bien que les tests dans le cloud puissent créer de la latence pour les développeurs, augmenter les coûts et parfois nécessiter des investissements dans DevOps des contrôles supplémentaires, cette technique fournit la couverture de test la plus fiable, précise et complète.

Vous devez avoir accès à des environnements isolés dans lesquels vous pouvez effectuer les tests. Idéalement, chaque développeur devrait disposer d'un AWS compte dédié afin d'éviter tout problème de dénomination des ressources qui peut survenir lorsque plusieurs développeurs travaillant sur le même code tentent de déployer ou d'invoquer des appels d'API sur des ressources portant des noms identiques. Ces environnements doivent être configurés avec les alertes et les contrôles appropriés afin d'éviter des dépenses inutiles. Par exemple, vous pouvez limiter le type, le niveau ou la taille des ressources qui peuvent être créées, et configurer des alertes par e-mail lorsque les coûts estimés dépassent un seuil donné.

Si vous devez partager un seul AWS compte avec d'autres développeurs, les processus de test automatisés doivent nommer les ressources de manière à ce qu'elles soient uniques pour chaque développeur. Par exemple, les scripts de mise à jour ou les fichiers de configuration TOML à l'origine des commandes AWS SAM CLI sam deploy ou sam sync peuvent spécifier automatiquement un nom de pile incluant le nom d'utilisateur du développeur local.

Les tests dans le cloud sont utiles pour toutes les phases de test, y compris les tests unitaires, les tests d'intégration et les end-to-end tests.

Utiliser des simulations si nécessaire

Les cadres simulés sont un outil précieux pour écrire des tests unitaires rapides. Ils sont particulièrement utiles lorsque les tests doivent couvrir une logique interne complexe, comme des calculs mathématiques ou financiers ou des simulations. Recherchez les tests unitaires qui comportent un grand nombre de cas de test ou de variations d'entrée, dans lesquels les entrées ne modifient ni le modèle ni le contenu des appels vers d'autres services cloud. La création de tests de simulation pour ces scénarios peut améliorer les temps d'itération des développeurs.

Le code couvert par des tests unitaires qui utilisent des tests de simulation doit également être couvert par des tests dans le cloud. Il s'agit d'une nécessité, car les simulations s'exécutent toujours sur l'ordinateur portable ou sur la machine de génération d'un développeur, et l'environnement peut être configuré différemment de ce qu'il sera dans le cloud. Par exemple, votre code peut inclure des fonctions Lambda qui utilisent plus de mémoire que ce que Lambda est censé allouer lorsqu'il est exécuté avec certains paramètres d'entrée. Votre code peut également inclure des variables d'environnement qui ne sont pas configurées de la même manière (ou pas du tout), et les différences pourraient entraîner un comportement différent ou un échec du code.

N'utilisez pas de simulations de services cloud pour valider l'implémentation correcte de ces intégrations de services. Bien qu'il soit acceptable de simuler un service cloud lorsque vous testez d'autres fonctionnalités, vous devez tester les appels de service cloud dans le cloud pour vérifier que la configuration et l'implémentation fonctionnelle sont correctes.

Les simulations peuvent apporter une valeur ajoutée aux tests unitaires, surtout lorsque vous testez fréquemment un grand nombre de cas. Cet avantage est réduit pour les tests d'intégration, car le niveau d'effort nécessaire pour implémenter les simulations nécessaires augmente avec le nombre de points de connexion. End-to-endles tests ne doivent pas utiliser de simulations, car ces tests portent généralement sur des états et une logique complexe qui ne peuvent pas être facilement simulés avec des frameworks fictifs.

Éviter d'utiliser des émulateurs

Les émulateurs peuvent être pratiques dans certains cas d'utilisation. Par exemple, une équipe de développement peut avoir un accès limité, irrégulier ou lent à Internet. Dans ce cas, les tests sur un émulateur peuvent être le seul moyen d'itérer de manière fiable sur le code avant de passer à un environnement cloud.

Dans la plupart des autres cas, utilisez les émulateurs avec parcimonie. Lorsque vous utilisez un émulateur, il peut s'avérer difficile d'innover et d'inclure de nouvelles fonctionnalités de AWS service dans vos tests jusqu'à ce que le fournisseur d'émulation publie une mise à jour garantissant la parité des fonctionnalités. Les émulateurs exigent aussi des dépenses initiales et continues liées à l'achat et à la configuration sur plusieurs systèmes de développement et machines de génération. En outre, de nombreux services cloud ne disposent pas d'émulateurs, et le choix d'une stratégie de test d'émulation empêchera l'utilisation de ces services (ce qui conduira à des solutions de contournement potentiellement plus coûteuses) ou produira du code et des configurations qui ne sont pas bien testés.

Si les tests d'émulation sont inévitables, profitez autant que possible des tests dans le cloud pour vous assurer que les configurations appropriées du cloud sont en place et pour tester les interactions avec d'autres services cloud qui ne peuvent être que simulées dans un environnement émulé.

Si nécessaire, les tests d'émulation peuvent fournir des commentaires pour les tests unitaires. Certains types de tests d'intégration et de end-to-end tests peuvent également être disponibles, en fonction des fonctionnalités et de la parité comportementale du logiciel d'émulation.

Accélérer les boucles de rétroaction

Lorsque vous effectuez des tests dans le cloud, utilisez les outils et les techniques qui vous permettent d'accélérer les boucles de rétroaction de développement. Par exemple, utilisez AWS SAM Accelerate et le mode de surveillance AWS CDK pour réduire le temps nécessaire au transfert des modifications de code vers un environnement cloud. Les exemples du référentiel GitHub Serverless Test Samples explorent certaines de ces techniques.

Nous vous recommandons également de créer et de tester les ressources cloud de votre machine locale le plus tôt possible au cours du développement, et pas seulement après une vérification du contrôle de source. Cette pratique permet d’accélérer l’exploration et l’expérimentation lors du développement de solutions. En outre, la possibilité d'automatiser le déploiement à partir d'une machine de développement vous permet de découvrir plus rapidement les problèmes de configuration du cloud et de réduire les efforts inutiles liés aux mises à jour et à l'approbation des modifications du contrôle de source.