Difficultés liées au test des applications sans serveur

Lorsque vous utilisez des émulateurs et des appels simulés pour tester votre application sans serveur sur votre poste de travail local, vous pouvez rencontrer des incohérences lors des tests au fur et à mesure que votre code progresse d'un environnement à l'autre dans votre pipeline. CI/CD Les tests unitaires que vous créez sur votre poste de travail pour valider la logique métier de votre application peuvent ne pas inclure ou ne pas représenter avec précision les aspects critiques des services cloud. Les tests complets ne peuvent pas être effectués localement de manière isolée. Ils nécessitent de vérifier les autorisations et les configurations entre plusieurs services.

Les sections suivantes décrivent les problèmes que vous pourriez rencontrer lors de l'implémentation d'une stratégie de test cloud. Les sections suivantes décrivent les défis auxquels les clients sont confrontés lorsqu'ils essaient de mettre en œuvre une stratégie de test dans le cloud, ainsi que nos conseils sur les meilleures pratiques pour obtenir une couverture de test efficace.

Exemple : fonction Lambda qui crée un compartiment Amazon S3

Si la logique d'une fonction Lambda dépend de la création d'un compartiment Amazon S3, un test complet doit confirmer qu'Amazon S3 a bien été appelé et que le compartiment a été créé avec succès. Dans le cas d’un test simulé, vous pouvez simuler une réponse de réussite et éventuellement ajouter un scénario de test pour gérer une réponse d’échec. Dans un scénario de test d'émulation, l'CreateBucketAPI peut être appelée, mais l'identité à l'origine de l'appel ne provient pas du fait que le service Lambda assume un rôle, et une authentification par espace réservé sera utilisée à la place. Il s'agit souvent de votre rôle ou de votre identité d'utilisateur le plus permissif.

Les configurations de simulation et d'émulation décrites précédemment vont très probablement tester ce que fera la fonction Lambda si elle appelle Amazon S3 avec succès (ou sans succès). Cependant, ces tests ne permettront pas de déterminer si la fonction Lambda est capable de créer correctement le bucket, compte tenu de la configuration de la fonction. Cette configuration est probablement représentée par l'infrastructure sous forme de code (IaC) pour des produits et services tels que AWS CloudFormation Terraform AWS SAM ou HashiCorp Terraform. L'un des problèmes possibles est que le rôle attribué à la fonction n'est pas associé à une politique autorisant l's3:CreateBucketaction, et que la fonction échouera donc toujours lorsqu'elle est déployée dans un environnement cloud.

Exemple : fonction Lambda qui traite les messages provenant d'Amazon SQS

Si une file d'attente Amazon Simple Queue Service (Amazon SQS) est la source d'une fonction Lambda, un test complet devrait vérifier que la fonction Lambda est correctement invoquée lorsqu'un message est placé dans une file d'attente. Les tests d'émulation et les tests fictifs sont généralement configurés pour exécuter directement le code de la fonction Lambda et pour simuler l'intégration Amazon SQS en transmettant une charge utile d'événement JSON (ou un objet désérialisé) comme entrée du gestionnaire de fonctions.

Les tests locaux qui simulent l'intégration Amazon SQS testeront ce que fera la fonction Lambda lorsqu'elle est appelée par Amazon SQS avec une charge utile donnée, mais ils ne garantissent pas qu'Amazon SQS invoquera correctement la fonction Lambda lorsqu'elle est déployée dans un environnement cloud.

Voici quelques exemples de problèmes de configuration que vous pouvez rencontrer avec Amazon SQS et Lambda :

• Le délai de visibilité d’Amazon SQS est trop court, ce qui entraîne des invocations multiples alors qu’une seule était prévue.

• Le rôle d'exécution de la fonction Lambda n'autorise pas la lecture de messages depuis la file d'attente (via sqs:ReceiveMessagesqs:DeleteMessage, ousqs:GetQueueAttributes).

• L’exemple d’événement transmis à la fonction Lambda dépasse le quota de taille de message Amazon SQS. Par conséquent, le test n’est pas valide, car Amazon SQS ne sera jamais en mesure d’envoyer un message de cette taille.

Comme le montrent ces exemples, les tests qui couvrent la logique métier mais pas les configurations entre les services cloud sont susceptibles de fournir des résultats peu fiables.