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 bureau local, vous pouvez rencontrer des incohérences de test lorsque votre code progresse d'un environnement à l'autre dans votre pipeline CI/CD. Les tests unitaires que vous créez sur votre bureau pour valider la logique métier de votre application peuvent ne pas inclure ou représenter avec précision des 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.

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

Si la logique d'une fonction Lambda dépend de la création d'un compartiment S3, un test complet doit confirmer qu'Amazon S3 a é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 parviendront pas à capturer l'éventualité où la fonction Lambda est capable de correctement créer le compartiment, 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 ne dispose pas d'une politique associée autorisant l'action s3:CreateBucket, et la fonction échouera donc lorsqu'elle sera déployée dans un environnement cloud.

Exemple : une fonction Lambda traite les messages d'une file d'attente Amazon SQS

Si une file d’attente Amazon SQS est la source d’une fonction Lambda, un test complet doit 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 simulés sont généralement configurés pour exécuter directement le code de la fonction Lambda et pour simuler l’intégration d’Amazon SQS en transmettant une charge utile d’événement JSON (ou un objet désérialisé) en tant qu’entrée du gestionnaire de fonction.

Les tests locaux qui simulent l'intégration d'Amazon SQS testeront ce que la fonction Lambda fera lorsqu'elle sera invoquée par Amazon SQS avec une charge utile donnée, mais ne vérifieront pas qu'Amazon SQS invoquera avec succès la fonction Lambda lors de son déploiement 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 ne permet pas de lire les messages de la file d'attente (via sqs:ReceiveMessage, sqs:DeleteMessage ou sqs: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.