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.
Techniques de tests pour les applications sans serveur
Il existe trois approches principales pour exécuter des tests sur le code d'une application sans serveur : les tests fictifs, les tests d'émulation et les tests dans le cloud. Vous pouvez généralement trouver une combinaison de ces approches utilisées dans le cadre d'un seul projet. Par exemple, vous pouvez utiliser des tests fictifs lorsque vous développez votre code localement, des tests d'émulation pour reproduire plus fidèlement le comportement du service avant le déploiement, et des tests cloud dans le cadre d'un processus d'intégration et de livraison continues (CI/CD) nocturnes.
Tests simulés
Les tests simulés sont une technique qui consiste à créer des objets de remplacement dans votre code afin de simuler le comportement des services cloud. Par exemple, vous pouvez écrire un test qui utilise une maquette du service Amazon S3, et vous pouvez configurer cette maquette pour qu'elle renvoie un objet de réponse spécifique chaque fois que la PutObject méthode est appelée. Lorsque le test s'exécute, la simulation renvoie la réponse sans appeler Amazon S3 ni aucun autre point de terminaison de service.
Ces objets de remplacement sont souvent générés par un cadre simulé afin de réduire le nombre d'implémentations nécessaires pour un test donné. Certains frameworks fictifs sont génériques tandis que d'autres sont conçus spécifiquement pour AWS SDKs.
Les simulations, tout comme les stubs, entrent dans la catégorie plus large des faux. Les simulacres diffèrent des émulateurs (abordés plus loin dans cette section) en ce sens que les maquettes sont généralement créées ou configurées par un développeur dans le cadre du code de test, tandis que les émulateurs sont des applications autonomes qui s'exposent APIs (comme REST APIs) de la même manière que les systèmes qu'ils émulent.
Les avantages de l’utilisation de simulations incluent les avantages suivants :
-
Mocks peut simuler des services tiers échappant au contrôle de votre application, tels que APIs des fournisseurs de logiciels en tant que service (SaaS), sans avoir besoin d'un accès direct à ces services.
-
Par ailleurs, les simulations sont utiles pour tester les conditions d'échec, en particulier lorsque ces conditions (comme dans le cas d'une panne de service) sont difficiles à simuler.
-
Comme les émulateurs, les frameworks fictifs peuvent permettre un développement local rapide une fois qu'ils ont été configurés.
-
Les simulations peuvent fournir un comportement de substitution pour pratiquement n’importe quel type d’objet. Les stratégies de simulations peuvent donc couvrir une plus grande variété de services que les émulateurs.
-
Lorsque de nouvelles fonctionnalités ou de nouveaux comportements sont disponibles, les tests fictifs peuvent réagir plus rapidement en utilisant (ou en recourant à) un framework de simulation générique, capable de simuler les nouvelles fonctionnalités dès que le AWS SDK mis à jour est disponible.
Les tests simulés présentent les inconvénients suivants :
-
Les simulations nécessitent généralement un effort d’installation et de configuration non négligeable, en particulier lorsqu’il s’agit de déterminer les valeurs de retour de différents services afin de simuler correctement les réponses.
-
Comme les simulations sont écrites ou configurées par les développeurs qui rédigent les tests, elles représentent une responsabilité supplémentaire pour eux.
-
Il se peut que vous deviez avoir accès au cloud afin de comprendre les valeurs des services APIs et de les rentabiliser.
-
Les maquettes peuvent également être difficiles à gérer, car elles nécessitent des mises à jour chaque fois que les signatures d'API cloud simulées changent, que les schémas de valeur de retour évoluent ou que la logique d'application testée est étendue pour faire des appels à de nouvelles. APIs Ces modifications créent une charge de travail supplémentaire en matière de développement de tests pour les développeurs.
-
Les tests fictifs peuvent réussir localement mais échouer dans le cloud, car ils simulent, au lieu de reproduire, le comportement de services réels, sans détecter les problèmes spécifiques à l'environnement.
-
Les frameworks fictifs, tels que les émulateurs, ne peuvent pas détecter les violations des politiques Gestion des identités et des accès AWS (IAM), les limites de quotas de service ou les contraintes de taille de charge utile, et ils ne déclenchent pas de services auxiliaires tels GuardDuty qu'Amazon CloudWatch AWS CloudTrail ou Amazon susceptibles d'affecter le comportement des applications dans un environnement déployé.
-
Bien que les simulations soient plus efficaces pour simuler ce que fera une application lorsque l'autorisation échoue ou qu'un quota est dépassé, les tests simulés ne permettent pas de déterminer le résultat réel qui se produira lorsque le code sera déployé dans l'environnement de production.
Tests d'émulation
Les tests d'émulation sont activés par des applications exécutées localement connues sous le nom d'émulateurs qui ressemblent à. Services AWS Les émulateurs sont APIs similaires à leurs homologues du cloud et fournissent des valeurs de retour similaires. Ils peuvent également simuler des changements d’état initiés par des appels d’API. Par exemple, un émulateur Amazon S3 peut stocker un objet sur le disque local lorsque la PutObject méthode est appelée. Lorsqu'il GetObject est appelé avec la même clé, l'émulateur lit le même objet sur le disque et le renvoie.
Les avantages des tests d'émulation sont les suivants :
-
Ils constituent l'environnement le plus familier pour les développeurs qui ont l'habitude de développer du code exclusivement dans un environnement local. Par exemple, si vous êtes habitué au développement d'une application à n niveaux, vous pouvez avoir un moteur de base de données et un serveur Web, similaires à ceux exécutés en production, exécutés sur votre machine locale pour fournir une capacité de test rapide, locale et isolée.
-
Il ne nécessite aucune modification de l'infrastructure cloud (comme les comptes cloud des développeurs), il est donc facile à mettre en œuvre avec les modèles de test existants. Les tests d'émulation offrent les avantages des itérations de développement rapides et locales.
Cependant, les émulateurs présentent plusieurs inconvénients :
-
Ils sont souvent difficiles à configurer et à reproduire, en particulier lorsqu'ils sont utilisés dans le cadre de CI/CD pipelines. Cela risque d'augmenter la charge de travail et la maintenance pour le personnel informatique ou pour les développeurs qui gèrent leurs propres installations de logiciels.
-
Les fonctionnalités émulées APIs sont généralement en retard par rapport aux modifications des services et peuvent entraver l'adoption de nouvelles fonctionnalités jusqu'à ce que le support soit ajouté.
-
Les émulateurs peuvent nécessiter une prise en charge, des mises à jour, des corrections de bogues ou des améliorations de parité des fonctionnalités, qui relèvent de la responsabilité de l'auteur de l'émulateur (qui est souvent une entreprise tierce).
-
Les tests basés sur des émulateurs peuvent fournir des résultats positifs localement, mais ils peuvent échouer dans le cloud en raison d'interactions avec d'autres aspects AWS tels que les politiques IAM et les quotas, qui ne sont généralement pas émulés.
-
Certains Services AWS ne disposent pas d'émulateurs. Par conséquent, si vous vous fiez uniquement à l'émulation, il se peut que vous ne disposiez pas d'une option de test satisfaisante pour certaines parties de votre application.
Tests dans le cloud
Les tests dans le cloud sont le processus qui consiste à exécuter des tests par rapport à du code déployé dans un environnement cloud, plutôt que dans un environnement de bureau. La valeur des tests dans le cloud augmente avec le développement d'applications natives cloud. Par exemple :
-
Vous pouvez exécuter des tests dans le cloud en fonction des fonctionnalités les plus récentes APIs , afin de vous assurer que vos tests reflètent les valeurs de retour et les comportements les plus récents, tout en AWS continuant à lancer de nouveaux services et fonctionnalités.
-
Vos tests peuvent couvrir les politiques IAM, les quotas de service, les configurations et tous les services.
-
Votre environnement de test cloud ressemble le plus étroitement à votre environnement d'exécution de production. Les tests que vous exécutez dans le cloud sont donc susceptibles d'obtenir les résultats les plus cohérents à mesure de leur progression dans les environnements.
Les inconvénients des tests dans le cloud sont les suivants :
-
Les déploiements vers des environnements cloud prennent généralement plus de temps que les déploiements vers des environnements de bureau. Des outils tels qu'AWS Serverless Application Model (AWS SAM) Accelerate, le mode de surveillance AWS Cloud Development Kit (AWS CDK) et SST
contribuent à réduire la latence associée aux itérations de déploiement cloud. -
Les tests dans le cloud peuvent entraîner des coûts de service supplémentaires, contrairement aux tests locaux, qui utilisent votre environnement de développement local.
-
Les tests dans le cloud peuvent être moins réalisables si vous ne disposez pas d'un accès Internet haut débit.
-
Dans les secteurs réglementés, les politiques de sécurité des entreprises peuvent restreindre l'accès des développeurs aux environnements cloud, ce qui rend difficile, voire impossible, l'exécution de tests cloud dans le cadre d'un flux de développement local.
-
Les limites de l'environnement sont souvent tracées au niveau de la pile dans les comptes partagés destinés aux environnements de développement, parfois en utilisant des politiques de type espace de noms telles que l'utilisation de préfixes pour identifier le propriétaire. Pour les environnements de pré-production et de production, les limites sont généralement définies au niveau du compte afin d'isoler les charges de travail de leurs bruyants voisins, de prendre en charge des contrôles de sécurité du moindre privilège et de protéger les données sensibles. L'obligation de créer des environnements isolés peut imposer une charge supplémentaire aux DevOps équipes, en particulier si elles font partie d'une entreprise qui applique des contrôles stricts sur les comptes et l'infrastructure.
