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.

Tester des applications sans serveur sur AWS

Amazon Web Services (Collaborateurscontributeurs)

Mars 2026 (historique du document)

Ce guide traite des méthodologies de test des applications sans serveur, décrit les défis que vous pourriez rencontrer lors des tests et présente les bonnes pratiques. Ces techniques de test ont pour but de vous aider à itérer plus rapidement et à publier votre code en toute confiance.

Ce guide s'adresse aux développeurs qui cherchent à établir des politiques de test pour leurs applications sans serveur. Vous pouvez utiliser le guide comme point de départ pour en savoir plus sur les politiques de test et consulter le référentiel Serverless Test Samples pour découvrir des exemples de tests conformes aux modèles et aux bonnes pratiques décrits dans ce guide. Ce guide décrit les méthodologies de test sans serveur, décrit les défis auxquels les clients sont confrontés lorsqu'ils testent des applications sans serveur et présente les meilleures pratiques pour tester des applications sans serveur. Ces techniques ont pour but d'aider les développeurs à itérer plus rapidement et à publier en toute confiance.

Présentation de

Les tests automatisés constituent des investissements essentiels qui contribuent à garantir la qualité des applications et la vitesse de développement. Les tests accélèrent également les commentaires pour les développeurs. En tant que développeur, vous souhaitez pouvoir itérer rapidement sur votre application et obtenir des commentaires sur la qualité de votre code. De nombreux développeurs ont l'habitude d'écrire des applications qu'ils déploient dans un environnement sur leur bureau, soit directement sur leur système d'exploitation, soit dans un environnement basé sur des conteneurs. Lorsque vous travaillez dans des environnements de bureau ou basés sur des conteneurs, vous écrivez généralement des tests par rapport à du code entièrement hébergé sur votre bureau. Toutefois, dans les applications sans serveur, les composants de l'architecture peuvent ne pas être déployables dans un environnement de bureau, mais n'exister que dans le cloud. Une architecture basée sur le cloud peut inclure des couches de persistance, des systèmes de messagerie, des structures de sécurité et d'autres composants. APIs Lorsque vous écrivez du code d'application qui repose sur ces composants, il peut être difficile de déterminer le meilleur moyen de concevoir et d'exécuter des tests.

Ce guide vous aide à adopter une stratégie de test qui réduit les frictions et les confusions, et qui améliore la qualité du code.

Conditions préalables

Ce guide part du principe que vous connaissez les bases des tests automatisés, notamment la manière dont les tests logiciels automatisés sont utilisés pour garantir la qualité des logiciels. Le guide fournit une introduction de haut niveau à une stratégie de test d'applications sans serveur et ne nécessite aucune expérience pratique en matière de rédaction de tests.

Définitions

Ce guide utilise les termes suivants :

Objectifs

Les bonnes pratiques présentées dans ce guide ont pour but de vous aider à atteindre deux objectifs principaux :

Améliorer la qualité de votre logiciel

La qualité d'une application dépend dans une large mesure de la capacité des développeurs à tester une variété de scénarios pour vérifier les fonctionnalités. Lorsque vous n'implémentez pas de tests automatisés ou, plus généralement, si vos tests ne couvrent pas correctement les scénarios requis, la qualité de votre application ne peut être ni déterminée ni garantie.

Dans une architecture basée sur des serveurs, les équipes sont en mesure de définir facilement une portée pour les tests. Ainsi, tout code qui s'exécute sur le serveur d'applications doit être testé. Les autres composants qui font appel au serveur, ou les dépendances que le serveur appelle, sont souvent considérés comme externes et hors de portée des tests par l'équipe responsable de l'application sur le serveur.

Les applications sans serveur consistent souvent en de petites unités de travail, telles que des fonctions AWS Lambda , qui s'exécutent dans leur propre environnement. Les équipes seront probablement responsables de plusieurs de ces plus petites unités au sein d'une même application. Certaines fonctionnalités de l'application peuvent être entièrement déléguées à des services gérés tels qu'Amazon Simple Storage Service (Amazon S3) ou Amazon Simple Queue Service (Amazon SQS) sans utiliser de code développé en interne. Les modèles traditionnels basés sur des serveurs pour les tests de logiciels peuvent exclure les services gérés en les considérant comme externes à l'application. Cela peut entraîner une couverture inadéquate, les scénarios critiques pouvant se limiter à des tests exploratoires manuels ou à quelques cas de test d'intégration dont les résultats varient en fonction de l'environnement. Par conséquent, l'adoption de politiques de test qui incluent les comportements des services gérés et les configurations cloud peut améliorer la qualité des logiciels.

Tester aux limites de l'architecture

Au fur et à mesure que les applications sans serveur se développent, elles se répartissent naturellement sur plusieurs composants architecturaux. Bien que cela utilise des fonctionnalités AWS distribuées, cela peut rendre end-to-end le comportement difficile à comprendre.

Identifier les limites naturelles

Lorsque vous concevez votre architecture conformément aux meilleures pratiques sans serveur (une fonction = une tâche, découplage), vous remarquerez des limites naturelles autour des sous-systèmes. Ces limites représentent des points de séparation logiques dans votre application.

Les limites en tant que contrats de test

Ces limites architecturales sont d'excellentes candidates pour tester les arêtes. Traitez chaque limite comme un contrat et vérifiez qu'elle se comporte conformément aux spécifications définies. Considérez ces limites comme des joints dans votre application où vous pouvez insérer une validation de test.

Principaux avantages

Les principaux avantages des tests aux limites de l'architecture sont les suivants :

Tester aux limites du code

Définissez des limites de code claires en séparant le code d'infrastructure, tel que le code Lambda, de votre logique métier principale. Cette séparation crée des étendues de test distinctes qui simplifient votre stratégie de test.

Le schéma des limites

Définissez deux limites de code claires dans vos fonctions Lambda :

Gestionnaire en tant qu'adaptateur (scope externe)

Votre gestionnaire de fonctions Lambda doit être une fine couche qui :

Logique métier (périmètre interne)

Votre logique métier de base doit :

Avantages des tests par périmètre

Cette approche basée sur les limites vous permet de tester la majeure partie de votre code sous forme de fonctions pures tout en minimisant et en ciblant les tests Lambda.

Diminuer le temps d'implémentation ou de modification des fonctionnalités

Vous pouvez minimiser l'effet des bogues logiciels et des problèmes de configuration sur les coûts et les délais en détectant ces problèmes au cours d'un cycle de développement itératif. Lorsqu'un développeur ne parvient pas à détecter ces problèmes, davantage de personnes doivent investir des efforts supplémentaires pour identifier les problèmes.

Une architecture sans serveur peut comprendre 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 qui valident à la fois le chemin heureux (où les interactions avec ces services se comportent comme prévu) et le chemin triste (où les appels échouent, renvoient des réponses inattendues ou se comportent différemment selon les environnements). Sans ces tests, vous pouvez rencontrer des problèmes liés aux différences entre votre environnement local et l'environnement déployé. Dans ce cas, vous devez passer plus de temps à essayer de reproduire et de vérifier un correctif, car chaque itération nécessite désormais de valider les modifications par rapport à un environnement différent de votre configuration préférée.

Une stratégie de test sans serveur appropriée améliore le temps d'itération en fournissant des résultats précis pour les tests qui incluent des appels à d'autres services.