Techniques de tests pour les applications sans serveur

Il existe trois approches principales pour exécuter des tests du code d'une application sans serveur : les tests simulés, les tests dans le cloud et les tests d'émulation. 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 simulés lorsque vous développez votre code localement, mais il peut être testé dans le cloud dans le cadre d'un processus nocturne d'intégration et de livraison continues (CI/CD).

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 CreateObjectmé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 cadres simulés 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 simulés peuvent réussir dans les environnements de bureau, mais échouer dans le cloud.

• Les frameworks fictifs, tels que les émulateurs, sont limités lorsqu'il s'agit de tester ou de détecter AWS Identity and Access Management (IAM) les limites des politiques ou des quotas.

• Bien que les simulations permettent de mieux simuler ce que fera une application en cas d'échec d'une autorisation ou de dépassement d'un quota, les tests ne peuvent pas déterminer le résultat qui se produira réellement lorsque le code est déployé dans l'environnement de production.

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 par rapport aux valeurs les plus récentes APIs et aux valeurs renvoyées.

• 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.

• Les tests dans le cloud nécessitent généralement des environnements cloud isolés les uns des autres. 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.

Tests d'émulation

Les tests d'émulation sont activés par des applications exécutées localement, appelées émulateurs, qui ressemblent à AWS des services. 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 PutObjectméthode est appelée. Lorsqu'il GetObjectest 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 à plusieurs niveaux, vous pouvez disposer d’un moteur de base de données et d’un serveur Web, similaires à ceux qui fonctionnent en production, exécutés sur votre ordinateur local afin de fournir une capacité de test rapide, locale et isolée.

• Ils ne nécessitent aucune modification de l'infrastructure cloud (telle que les comptes cloud des développeurs). Ils sont donc faciles à implémenter 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 pipelines CI/CD. 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 AWS services 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.