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.

Commenter tester des fonctions et des applications sans serveur

Le test des fonctions sans serveur fait appel à des types et techniques de test traditionnels, mais vous devez également envisager de tester les applications sans serveur dans leur ensemble. Cloud-based les tests fournissent la mesure la plus précise de la qualité de vos fonctions et de vos applications sans serveur.

Une architecture d’application sans serveur comprend des services gérés qui fournissent des fonctionnalités d’applications critiques par le biais d’appels d’API. C’est pourquoi votre cycle de développement doit inclure des tests automatisés qui vérifient la fonctionnalité lorsque votre fonction et vos services interagissent.

Si vous ne créez pas de tests basés sur le cloud, vous pouvez rencontrer des problèmes en raison des différences entre votre environnement local et l’environnement déployé. Votre processus d’intégration continue doit exécuter des tests sur une série de ressources allouées dans le cloud avant de promouvoir votre code vers l’environnement de déploiement suivant, comme l’assurance qualité, la mise en place ou la production.

Poursuivez la lecture de ce petit guide pour en savoir plus sur les stratégies de test pour les applications sans serveur, ou rendez-vous sur le référentiel Serverless Test Samples pour vous plonger dans des exemples pratiques, spécifiques au langage et à l’exécution que vous avez choisis.

Pour les tests sans serveur, vous pouvez toujours écrire des tests unitaires, d'intégration et de bout en bout.

Résultats commerciaux ciblés

La mise en place des tests de solutions sans serveur peut prendre plus de temps. Vous devez vérifier les interactions déclenchées par des événements entre les services. Gardez ces raisons commerciales pratiques à l'esprit lorsque vous lisez ce guide :

La qualité d'une application dépend du test de nombreux scénarios. Examinez vos scénarios commerciaux et automatisez les tests pour les exécuter sur les services cloud. Cela améliore la qualité de votre candidature.

Les bogues et les problèmes de configuration sont moins coûteux s'ils sont détectés tôt dans le cycle de développement. Les problèmes qui ne sont pas détectés avant la production demandent plus d'efforts et plus de personnel pour les résoudre.

Une bonne stratégie de test sans serveur améliore la qualité des logiciels et accélère les itérations. Il vérifie que vos fonctions et applications Lambda fonctionnent comme prévu dans le cloud.

Que faut-il tester ?

Nous recommandons une stratégie de test qui teste les comportements des services gérés, la configuration du cloud, les politiques de sécurité et l'intégration à votre code. Les tests de comportement, également appelés tests de boîte noire, vérifient qu'un système fonctionne comme prévu sans en connaître les composants internes.

Dans une architecture serveur traditionnelle, les équipes testent souvent uniquement le code qui s'exécute sur le serveur d'applications. Ils considèrent les autres composants, services ou dépendances comme externes et hors de portée.

Les applications sans serveur sont constituées de petites unités de travail. Les exemples incluent les fonctions Lambda qui extraient des produits d'une base de données, traitent des éléments d'une file d'attente ou redimensionnent une image stockée. Chaque composant s'exécute dans son propre environnement. Les équipes gèrent bon nombre de ces petites unités au sein d'une seule application.

Certaines fonctionnalités peuvent être entièrement gérées par des services gérés tels qu'Amazon S3, ou créées sans code personnalisé. Il n'est pas nécessaire de tester ces services gérés. Cependant, vous devez tester la manière dont votre code s'intègre à eux.

Comment tester le sans serveur

Vous savez probablement comment tester les applications déployées localement. Vous écrivez des tests en fonction du code sur votre bureau ou dans des conteneurs. Par exemple, vous pouvez appeler un service Web local, puis vérifier la réponse.

Les solutions sans serveur utilisent votre code de fonction et des services gérés basés sur le cloud, tels que les files d'attente, les bases de données, les bus d'événements et les systèmes de messagerie. Ces composants se connectent via une architecture pilotée par les événements, dans laquelle les messages, appelés événements, circulent d'une ressource à une autre. Certaines interactions sont synchrones, comme un service Web qui renvoie des résultats immédiatement.

D'autres sont asynchrones, comme le placement d'éléments dans une file d'attente ou le démarrage d'une étape du flux de travail. Votre stratégie de test doit couvrir les deux types et tester les interactions entre les services. Pour les interactions asynchrones, vous devrez peut-être détecter des effets secondaires dans les composants en aval qui ne sont pas immédiatement visibles.

Vous ne pouvez pas répliquer entièrement un environnement cloud localement. Cela inclut les files d'attente, les tables de base de données, les bus d'événements et les politiques de sécurité. Les différences entre les environnements locaux et cloud sont à l'origine de problèmes. Ces différences augmentent le temps de reproduction et de correction des bogues.

Dans les applications sans serveur, les composants existent entièrement dans le cloud. Des tests sur le code et les services du cloud sont nécessaires pour développer des fonctionnalités et corriger des bogues.

Techniques de test

Votre stratégie de test comprend probablement une combinaison de techniques. Vous utilisez des tests interactifs rapides pour déboguer les fonctions de la console. Vous écrivez des tests unitaires automatisés pour vérifier la logique métier. Vous vérifiez les appels vers des services externes à l'aide de simulacres. Vous pouvez également effectuer des tests sur des émulateurs qui imitent un service.

Tests dans le cloud

Les tests dans le cloud sont utiles pour toutes les phases des tests : tests unitaires, tests d'intégration et tests de bout en bout. Les tests exécutés sur du code et des services basés sur le cloud fournissent la mesure la plus précise de la qualité de votre code.

Un moyen simple d'exécuter une fonction Lambda dans le cloud consiste à lancer un événement de test dans le Console de gestion AWS. Un événement de test est une entrée JSON pour votre fonction. Si votre fonction ne nécessite aucune saisie, l'événement peut être un document JSON vide({}). La console fournit des exemples d'événements pour de nombreuses intégrations de services. Vous pouvez partager des événements avec votre équipe pour faciliter les tests.

Découvrez comment déboguer un exemple de fonction dans la console.

Des exemples d’automatisation des tests sont disponibles dans le référentiel Serverless Test Samples. La ligne de commande suivante exécute un exemple de test d’intégration Python automatique :

python -m pytest -s tests/integration -v

Bien que le test soit exécuté localement, il fait appel à des ressources basées sur le cloud. Ces ressources ont été déployées à l'aide de l'outil de ligne de AWS SAM commande AWS Serverless Application Model and. Le code de test extrait d'abord les sorties de la pile déployée, telles que le point de terminaison de l'API, l'ARN de la fonction et le rôle de sécurité.

Il envoie ensuite une demande au point de terminaison de l'API. La réponse contient une liste de compartiments Amazon S3. Ce test est exécuté sur des ressources basées sur le cloud pour vérifier qu'elles sont déployées, sécurisées et fonctionnent.

========================= test session starts =========================
      platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
      -- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
      cachedir: .pytest_cache
      rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
      plugins: mock-3.10.0
      collected 1 item                                                                                                        

      tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway 

      --> Stack outputs:

        HelloWorldApi
        = https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

        PythonTestDemo
        = arn:aws:lambda:us-east-2:123456789012:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
        > Hello World Lambda Function ARN

        PythonTestDemoIamRole
        = arn:aws:iam::123456789012:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
        > Implicit IAM Role created for Hello World function

      --> Found API endpoint for "testing-apigw-lambda" stack...
      --> https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
      API Gateway response:
      amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
      PASSED

      ========================= 1 passed in 1.53s ========================= 
      

Pour le développement d’applications natives cloud, les tests dans le cloud offrent les avantages suivants :

Les tests dans le cloud présentent certains inconvénients. Les déploiements dans le cloud prennent généralement plus de temps que les déploiements de postes de travail locaux.

Des outils tels que AWS Serverless Application Model (AWS SAM) Accelerate, le mode de surveillance du AWS Cloud Development Kit (AWS CDK) et SST (tiers) réduisent cette latence. Ces outils surveillent votre infrastructure et votre code, puis déploient automatiquement les mises à jour de votre environnement cloud.

Contrairement aux tests locaux, les tests dans le cloud utilisent des ressources qui peuvent entraîner des coûts. Les environnements de test isolés peuvent ajouter du travail à vos DevOps équipes, en particulier dans les organisations où les contrôles de comptes sont stricts. Malgré cela, le temps consacré par les développeurs à la mise en place d'un environnement local complexe peut être plus coûteux que l'utilisation d'environnements cloud jetables conçus avec des outils d'infrastructure en tant que code.

Même en tenant compte de ces considérations, les tests dans le cloud restent le meilleur moyen de garantir la qualité de vos solutions sans serveur.

Tester avec des simulations

Les tests avec des simulations sont une technique qui consiste à créer des objets de remplacement dans votre code afin de simuler le comportement d’un service cloud.

Par exemple, vous pouvez écrire un test qui utilise une simulation du service Amazon S3. La maquette renvoie une réponse définie chaque fois que la CreateObject méthode est appelée. Il n'appelle pas Amazon S3 ni aucun autre point de terminaison de service.

Les frameworks fictifs génèrent souvent des objets fictifs pour vous. Certains frameworks sont génériques. D'autres ciblent AWS les SDK, tels que Moto, une bibliothèque Python pour les services de simulation. AWS

Les objets fictifs diffèrent des émulateurs. Les développeurs créent des simulations dans le cadre du code de test. Les émulateurs sont des applications autonomes qui présentent les mêmes fonctionnalités que les systèmes qu'ils imitent.

Les avantages de l’utilisation de simulations incluent les avantages suivants :

Les tests simulés présentent les inconvénients suivants :

Tester localement en utilisant   AWS SAM INTERFACE DE LIGNE DE COMMANDE (CLI)

Utilisez AWS SAM CLI pour tester vos fonctions dans des conteneurs Docker en utilisant le même environnement d’exécution que AWS Lambda. Vous pouvez tester la logique d’une fonction et le traitement des événements localement sans déploiement dans le cloud. Si votre fonction effectue des appels d'API vers d'autres personnes Services AWS, ces appels atteignent de véritables AWS ressources.

Les avantages des tests avec des conteneurs locaux incluent les suivants :

Les tests avec les conteneurs locaux présentent les limites suivantes :

Tester avec émulation

Les émulateurs sont des applications exécutées localement qui imitent les AWS services en fournissant des API et des valeurs de retour similaires. LocalStack est un outil d'émulation populaire qui fournit un environnement de développement local complet pour tester les intégrations de services.

LocalStack est un émulateur AWS Cloud que vous pouvez utiliser pour tester localement des applications sans serveur. Vous pouvez tester les fonctions Lambda qui s'intègrent à des services tels que DynamoDB, Amazon S3 et Amazon SQS sans vous connecter à des services réels. AWS Vous pouvez l'utiliser LocalStack dans la AWS boîte à outils pour VS Code.

Les avantages des tests avec émulateurs sont les suivants :

Les tests avec des émulateurs présentent les inconvénients suivants :

Bonnes pratiques

Les sections suivantes fournissent des recommandations pour réussir les tests d’applications sans serveur.

Vous trouverez des exemples pratiques de tests et d’automatisation des tests dans le référentiel Serverless Test Samples.

Prioriser les tests dans le cloud

Les tests dans le cloud fournissent la couverture de test la plus fiable, la plus précise et la plus complète. La réalisation de tests dans le contexte du cloud permet de tester de manière exhaustive non seulement la logique métier, mais également les politiques de sécurité, les configurations de service, les quotas, ainsi que les signatures d'API et les valeurs de retour les plus récentes.

Structurer votre code pour le rendre testable

Simplifiez vos tests et vos fonctions Lambda en séparant Lambda-specific le code de votre logique métier principale.

Votre gestionnaire de fonctions Lambda doit être un adaptateur léger qui prend en charge les données des événements et ne transmet que les détails importants à votre ou vos méthodes de logique métier. Grâce à cette stratégie, vous pouvez réaliser des tests complets autour de votre logique métier sans vous soucier des Lambda-specific détails. Vos fonctions AWS Lambda ne devraient pas nécessiter la configuration d'un environnement complexe ou d'un grand nombre de dépendances pour créer et initialiser le composant testé.

D’une manière générale, vous devez écrire un gestionnaire qui extrait et valide les données des objets d’événement et de contexte entrants, puis envoie ces données aux méthodes qui exécutent votre logique métier.

Accélérer les boucles de rétroaction du développement

Il existe des outils et des techniques permettant d’accélérer les boucles de rétroaction du développement. Par exemple, AWS SAM Accelerate et le mode de surveillance AWS CDK réduisent tous deux le temps nécessaire à la mise à jour des environnements 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 le plus tôt possible au cours du développement, et pas seulement après une vérification du contrôle du code source. Cette pratique permet d’accélérer l’exploration et l’expérimentation lors du développement de solutions. En outre, l’automatisation du 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 aux processus de révision du code.

Se concentrer sur les tests d’intégration

Lors de la création d’applications avec Lambda, il est recommandé de tester les composants ensemble.

Les tests exécutés sur deux composants architecturaux ou plus sont appelés tests d’intégration. L'objectif des tests d'intégration est de comprendre non seulement comment votre code s'exécute entre les composants, mais aussi comment se comporte l'environnement qui héberge votre code. End-to-end les tests sont des types particuliers de tests d'intégration qui vérifient les comportements de l'ensemble d'une application.

Pour créer des tests d’intégration, déployez votre application dans un environnement cloud. Cela peut se faire à partir d'un environnement local ou par le biais d'un CI/CD pipeline. Rédigez ensuite des tests pour exécuter le système sous test (SUT) et valider le comportement attendu.

Par exemple, le système testé pourrait être une application qui utilise API Gateway, Lambda et DynamoDB. Un test peut effectuer un appel HTTP synthétique vers un point de terminaison d’API Gateway et valider que la réponse contient la charge utile attendue. Ce test confirme que le code AWS Lambda est correct et que chaque service est correctement configuré pour gérer la demande, y compris les autorisations IAM entre eux. En outre, vous pouvez concevoir le test pour écrire des enregistrements de différentes tailles afin de vérifier que vos quotas de service, tels que la taille d’enregistrement maximale dans DynamoDB, sont correctement configurés.

Créer des environnements de test isolés

Les tests dans le cloud nécessitent généralement des environnements de développement isolés, de sorte que les tests, les données et les événements ne se chevauchent pas.

L'une des approches consiste à fournir à chaque développeur un AWS compte dédié. Cela permet d'éviter les conflits avec la dénomination des ressources qui peuvent survenir lorsque plusieurs développeurs travaillent dans une base de code partagée, tentent de déployer des ressources ou invoquent une API.

Les processus de test automatisés doivent créer des ressources portant un nom unique pour chaque pile. Par exemple, vous pouvez configurer des scripts ou des fichiers de configuration TOML de sorte que les commandes AWS SAM CLI sam deploy ou sam sync spécifient automatiquement une pile avec un préfixe unique.

Dans certains cas, les développeurs partagent un AWS compte. Cela peut être dû au fait que votre stack contient des ressources coûteuses à exploiter ou à provisionner et à configurer. Par exemple, une base de données peut être partagée pour faciliter la configuration et l'ensemencement corrects des données

Si les développeurs partagent un compte, vous devez définir des limites afin d’identifier les propriétaires et d’éliminer les chevauchements. L’un des moyens d’y parvenir est de mettre des préfixes sur les noms de piles avec les identifiants d’utilisateurs des développeurs. Une autre approche populaire consiste à configurer des piles basées sur des branches de code. Avec les limites de branches, les environnements sont isolés, mais les développeurs peuvent toujours partager des ressources, telles qu’une base de données relationnelle. Cette approche est une bonne pratique lorsque les développeurs travaillent sur plusieurs branches à la fois.

Les tests dans le cloud sont utiles pour toutes les phases des tests, y compris les tests unitaires, les tests d’intégration et les tests de bout en bout. Il est essentiel de maintenir une isolation adéquate, mais vous souhaitez tout de même que votre environnement d’assurance qualité ressemble le plus possible à votre environnement de production. C’est pourquoi les équipes ajoutent des processus de contrôle des modifications pour les environnements d’assurance qualité.

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 et de mettre en œuvre des contrôles de sécurité du moindre privilège pour protéger les données sensibles. Les charges de travail sont soumises à des quotas. Vous ne voulez pas que vos tests consomment les quotas alloués à la production (voisin bruyant) ou qu’ils aient accès aux données des clients. Les tests de charge constituent une autre activité que vous devez isoler de votre pile de production.

Dans tous les cas, les environnements doivent être configurés avec des alertes et des contrôles 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é.

Utiliser des simulations pour isoler la logique métier

Les cadres simulés sont un outil précieux pour écrire des tests unitaires rapides. Ils sont particulièrement utiles lorsque les tests couvrent une logique interne complexe, tels que 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 ces entrées ne modifient ni le modèle ni le contenu des appels vers d’autres services cloud.

Le code couvert par des tests unitaires avec des simulations doit également être couvert par des tests dans le cloud. Cela est recommandé, car un ordinateur portable de développeur ou un environnement de machine de génération peuvent être configurés différemment d’un environnement de production dans le cloud. Par exemple, vos fonctions Lambda peuvent utiliser plus de mémoire ou de temps que ce qui est alloué lorsqu’elles sont exécutées 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 peuvent entraîner un comportement différent ou un échec du code.

Les avantages des simulations sont moindres pour les tests d'intégration, car le niveau d'effort pour implémenter les simulations nécessaires augmente avec le nombre de points de connexion. End-to-end les tests ne doivent pas utiliser de simulations, car ces tests traitent généralement d'états et de logiques complexes qui ne peuvent pas être facilement simulés avec des frameworks fictifs.

Enfin, évitez d’utiliser des services cloud simulés pour valider la bonne mise en œuvre des appels de service. Au lieu de cela, faites des appels de services dans le cloud pour valider le comportement, la configuration et la mise en œuvre fonctionnelle.

Utiliser les émulateurs avec parcimonie

Les émulateurs peuvent être pratiques dans certains cas d’utilisation, par exemple pour une équipe de développement disposant d’un accès Internet limité, peu fiable ou lent. Mais, dans la plupart des cas, choisissez d’utiliser les émulateurs avec parcimonie.

En évitant les émulateurs, vous pouvez créer et innover avec les dernières fonctionnalités de service et les API les plus récentes. Vous n'êtes pas obligé d'attendre les versions des fournisseurs pour atteindre la parité des fonctionnalités. Vous réduisez vos dépenses initiales et permanentes liées à l'achat et à la configuration de plusieurs systèmes de développement et de construction de machines. De plus, vous évitez le problème que de nombreux services cloud ne disposent tout simplement pas d'émulateurs. Une stratégie de test qui repose sur l'émulation rend impossible l'utilisation de ces services (ce qui peut entraîner des solutions de contournement plus coûteuses) ou la production de code et de configurations qui ne sont pas bien testés.

Lorsque vous utilisez l’émulation à des fins de test, vous devez tout de même effectuer des tests dans le cloud pour vérifier la configuration et tester les interactions avec les services cloud qui ne peuvent être simulés que dans un environnement émulé.

Défis liés aux tests locaux

Lorsque vous utilisez des émulateurs et des appels simulés pour effectuer des tests sur votre poste de travail local, vous pouvez rencontrer des incohérences au fur et à mesure que votre code progresse d'un environnement à l'autre dans votre pipeline. CI/CD Les tests unitaires visant à valider la logique métier de votre application sur votre poste de travail peuvent ne pas tester avec précision les aspects critiques des services cloud.

Les exemples suivants présentent des cas à surveiller lors de tests locaux à l’aide de simulations et d’émulateurs :

Exemple : la fonction Lambda 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 devrait confirmer qu'Amazon S3 a été appelé et que le compartiment a été créé avec succès.

Les configurations de simulation et d'émulation testent ce que fait la fonction Lambda si elle appelle Amazon S3 ; toutefois, ces tests ne permettent pas de vérifier que la fonction Lambda, telle que configurée, est capable de créer correctement le compartiment Amazon S3. Vous devez vous assurer que le rôle attribué à la fonction dispose d’une politique de sécurité attachée qui autorise la fonction à effectuer l’action s3:CreateBucket. Dans le cas contraire, la fonction risque d'échouer lorsqu'elle est déployée dans un environnement cloud.

Exemple : la 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 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 fonction.

Les tests locaux qui simulent l'intégration d'Amazon SQS testent ce que fait la fonction Lambda lorsqu'elle est appelée par Amazon SQS avec une charge utile donnée, mais le test ne permet pas de vérifier qu'Amazon SQS invoque 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 :

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.

FAQ

J’ai une fonction Lambda qui effectue des calculs et renvoie un résultat sans appeler aucun autre service. Dois-je vraiment le tester dans le cloud ?

Oui. Les fonctions Lambda comportent des paramètres de configuration susceptibles de modifier le résultat du test. Tout le code de la fonction Lambda dépend des paramètres de délai d’attente et de mémoire, ce qui peut entraîner l’échec de la fonction si ces paramètres ne sont pas définis correctement.

Les politiques Lambda permettent également la journalisation standard des sorties sur Amazon CloudWatch. Même si votre code n'appelle pas CloudWatch directement, une autorisation est nécessaire pour activer la journalisation. Cette autorisation requise ne peut pas être simulée ou émulée avec précision.

Comment les tests dans le cloud peuvent-ils faciliter les tests unitaires ? S'il se trouve dans le cloud et se connecte à d'autres ressources, n'est-ce pas un test d'intégration ?

Nous définissons les tests unitaires comme des tests qui opèrent sur des composants architecturaux de manière isolée, mais cela n'empêche pas les tests d'inclure des composants susceptibles d'appeler d'autres services ou d'utiliser certaines communications réseau.

De nombreuses applications sans serveur possèdent des composants architecturaux qui peuvent être testés de manière isolée, même dans le cloud. Un exemple est celui d’une fonction Lambda qui prend une entrée, traite les données et envoie un message à une file d’attente Amazon SQS. Un test unitaire de cette fonction devrait permettre de vérifier si les valeurs d’entrée entraînent la présence de certaines valeurs dans le message en file d’attente.

Prenons l’exemple d’un test écrit en utilisant le modèle organiser, agir, affirmer :

Une approche de test simulé consiste à simuler la file d’attente avec un objet simulé en cours de traitement et à créer une instance en cours de traitement de la classe ou du module contenant le code de la fonction Lambda. Pendant la phase d’assertion, le message en file d’attente est récupéré dans l’objet simulé.

Dans une approche basée sur le cloud, le test crée une file d’attente Amazon SQS pour les besoins du test et déploie la fonction Lambda avec des variables d’environnement configurées pour utiliser la file d’attente Amazon SQS isolée comme destination de sortie. Après avoir exécuté la fonction Lambda, le test récupère le message dans la file d’attente Amazon SQS.

Le test basé sur le cloud exécuterait le même code, confirmerait le même comportement et validerait l'exactitude fonctionnelle de l'application. Cependant, cela aurait l'avantage supplémentaire de pouvoir valider les paramètres de la fonction Lambda : le rôle IAM, les politiques IAM et les paramètres de temporisation et de mémoire de la fonction.

Prochaines étapes et ressources

Les ressources suivantes vous permettront d’en savoir plus et de découvrir des exemples pratiques de tests.

Exemples d’implémentations

Le référentiel Serverless Test Samples sur GitHub contient des exemples concrets de tests qui suivent les modèles et les meilleures pratiques décrits dans ce guide. Le référentiel contient des exemples de code et des descriptions guidées des processus de simulation, d’émulation et de test dans le cloud décrits dans les sections précédentes. Utilisez ce référentiel pour vous tenir au courant des derniers conseils de test sans serveur de AWS.

Suggestions de lecture

Visitez Serverless Land pour accéder aux derniers blogs, vidéos et formations sur les technologies AWS sans serveur.

La lecture des articles de AWS blog suivants est également recommandée :

Outils