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.
# Bonnes pratiques pour tester les applications sans serveur
Les sections suivantes décrivent les bonnes pratiques pour obtenir une couverture efficace lors du test d'applications sans serveur.
## Prioriser les tests dans le cloud
Pour des applications bien conçues, vous pouvez utiliser diverses techniques de test pour répondre à un éventail d'exigences et de conditions. Cependant, sur la base des outils actuels, nous vous recommandons de vous concentrer autant que possible sur les tests dans le cloud. Bien que les tests dans le cloud puissent créer de la latence pour les développeurs, augmenter les coûts et parfois nécessiter des investissements dans DevOps des contrôles supplémentaires, cette technique fournit la couverture de test la plus fiable, précise et complète.
Vous devez avoir accès à des environnements isolés dans lesquels vous pouvez effectuer les tests. Idéalement, chaque développeur devrait disposer d'un service dédié Compte AWS afin d'éviter tout problème de dénomination des ressources qui peut survenir lorsque plusieurs développeurs travaillant sur le même code tentent de déployer ou d'invoquer des appels d'API sur des ressources portant des noms identiques. Ces environnements doivent être configurés avec les alertes et les contrôles appropriés 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é.
Si vous devez partager un single Compte AWS avec d'autres développeurs, les processus de test automatisés doivent nommer les ressources de manière à ce qu'elles soient uniques pour chaque développeur. Par exemple, les scripts de mise à jour ou les fichiers de configuration TOML à l'origine des commandes AWS SAM CLI [sam deploy](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html) [ou sam sync](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-sync.html) peuvent spécifier automatiquement un nom de pile incluant le nom d'utilisateur du développeur local.
Les tests dans le cloud sont utiles pour toutes les phases de test, y compris les tests unitaires, les tests d'intégration et les end-to-end tests.
## Utiliser des simulations si nécessaire
Les cadres simulés sont un outil précieux pour écrire des tests unitaires rapides. Ils sont particulièrement utiles lorsque les tests doivent couvrir une logique interne complexe, comme 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 les entrées ne modifient ni le modèle ni le contenu des appels vers d'autres services cloud. La création de tests de simulation pour ces scénarios peut améliorer les temps d'itération des développeurs.
Le code couvert par des tests unitaires qui utilisent des tests de simulation doit également être couvert par des tests dans le cloud. Cela est nécessaire car les maquettes fonctionnent toujours sur l'ordinateur portable ou sur la machine de construction d'un développeur, et l'environnement peut être configuré différemment de ce qu'il sera dans le cloud. Par exemple, votre code peut inclure des AWS Lambda fonctions qui utilisent plus de mémoire ou prennent plus de temps que ce que Lambda est configuré pour allouer lorsqu'il est exécuté 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.
N'utilisez pas de simulacres de services cloud pour valider la bonne mise en œuvre de ces intégrations de services. Bien qu'il soit acceptable de simuler un service cloud lorsque vous testez d'autres fonctionnalités, vous devez tester les appels de service cloud dans le cloud pour valider la configuration et l'implémentation fonctionnelle correctes.
Les simulations peuvent apporter une valeur ajoutée aux tests unitaires, en particulier lorsque vous testez fréquemment un grand nombre de cas. Cet avantage est réduit pour les tests d'intégration, car le niveau d'effort nécessaire pour implémenter les simulations nécessaires augmente avec le nombre de points de connexion. End-to-endles tests ne doivent pas utiliser de simulations, car ces tests portent généralement sur des états et une logique complexe qui ne peuvent pas être facilement simulés avec des frameworks fictifs.
## Comprenez les inconvénients des tests d'émulation
Les émulateurs peuvent être un choix pratique pour des cas d'utilisation spécifiques. Par exemple, une équipe de développement dont l'accès à Internet est limité, incohérent ou lent peut trouver que les tests d'émulation constituent le moyen le plus fiable d'itérer sur le code avant de passer à un environnement cloud.
Dans la plupart des autres cas, utilisez les émulateurs de manière sélective. Lorsque vous comptez beaucoup sur un émulateur, il peut s'avérer difficile d'intégrer de nouvelles fonctionnalités de AWS service à vos tests jusqu'à ce que le fournisseur d'émulation publie une mise à jour garantissant la parité des fonctionnalités. Les émulateurs nécessitent également un investissement initial et continu pour l'installation et la configuration des systèmes de développement et des machines de construction. En outre, de nombreux services cloud ne disposent pas d'émulateurs ; le choix d'une stratégie privilégiant l'émulation peut soit empêcher l'utilisation de ces services, soit produire du code et des configurations qui ne sont pas correctement testés par rapport au comportement réel des services.
Si vous utilisez des tests d'émulation, complétez-les autant que possible par des tests sur le cloud afin de valider que les configurations cloud appropriées sont en place et de tester les interactions avec des services qui ne peuvent être simulés ou simulés que dans un environnement émulé.
Les tests d'émulation peuvent fournir des informations rapides pour les tests unitaires et, en fonction des fonctionnalités et de la parité comportementale du logiciel d'émulation, peuvent également prendre en charge certaines intégrations et certains end-to-end tests.
## Tests de portée à travers les limites naturelles
À mesure que les applications sans serveur intègrent de plus en plus de composants architecturaux, des limites naturelles apparaissent autour des sous-systèmes, en particulier lorsque l'on suit les meilleures pratiques telles que les fonctions à usage unique et le découplage piloté par les événements. Ces limites constituent des zones de test efficaces où vous pouvez valider les contrats entre les composants.
### Identifier les limites de l'architecture
Recherchez des coutures naturelles dans la conception de votre application :
+ Entre les services, comme une EventBridge règle Amazon reliant un éditeur à un consommateur
+ À la périphérie des API, tels que les points de terminaison Amazon API Gateway qui font face aux fonctions Lambda
+ Autour des flux de travail, tels que l' AWS Step Functions orchestration de plusieurs services
+ Au niveau des couches de stockage, telles que les flux Amazon DynamoDB déclenchant un traitement en aval
### Séparer le code Lambda de la logique métier
Simplifiez vos tests en isolant le code Lambda de la logique métier principale. Votre gestionnaire Lambda doit agir comme un adaptateur léger entre le AWS runtime et la logique de votre application. Il doit extraire et valider les données des événements, puis les déléguer à une fonction testable qui n'a aucune dépendance Lambda. Cela rend votre logique métier portable, plus facile à raisonner et simple à tester sans vous moquer des objets Lambda ou configurer des environnements complexes.
### Traitez les limites comme des contrats
Testez à la limite, pas à travers elle. Validez ce qui franchit la limite sans avoir besoin de l'ensemble du système en aval. Ces mêmes limites servent également de points d'observabilité dans la production. Les joints architecturaux que vous testez peuvent être instrumentés pour être surveillés à l'aide d'Amazon CloudWatch Logs, de AWS X-Ray traces et d' EventBridgeévénements.
## Utiliser des harnais de test pour les flux de travail asynchrones
Les applications sans serveur reposent souvent sur des modèles asynchrones, dans lesquels les événements déclenchent le traitement, les messages circulent dans les files d'attente et les flux de travail couvrent plusieurs services sans réponse immédiate. Vous ne pouvez pas simplement invoquer une fonction et inspecter une valeur de retour. Le résultat peut apparaître ultérieurement dans une base de données, un flux de journal ou un autre service.
Un *harnais de test* consiste à tester l'infrastructure que vous déployez parallèlement à votre application afin d'observer et de valider ce comportement asynchrone. Les harnais de test incluent généralement :
+ Des écouteurs d'événements qui s'abonnent aux mêmes événements que ceux produits par votre application
+ Mécanismes de stockage (tels que des tables DynamoDB ou des compartiments Amazon S3) permettant de capturer les résultats des tests
+ Logique d'interrogation dans votre code de test qui attend l'apparition des résultats attendus
Votre code de test déclenche un événement, attend la fin du flux de travail, puis interroge le harnais de test pour vérifier que le résultat attendu s'est produit.
Voici les bonnes pratiques associées :
+ **Définissez clairement SLAs les opérations asynchrones** : déterminez la durée que devraient prendre les flux de travail et utilisez-les comme délais d'expiration des interrogations dans vos tests
+ **Utiliser des identifiants uniques pour isoler les tests** : générez des noms de fichiers, des messages IDs ou des jetons de corrélation uniques par test afin d'éviter toute interférence entre les tests
+ **Déployez une infrastructure de test parallèlement à votre application** : incluez des ressources de harnais de test dans vos infrastructure-as-code modèles afin qu'elles restent synchronisées au fur et à mesure de l'évolution de votre application
+ **Nettoyez les données de test après les tests** : cela évite l'accumulation d'artefacts de test dans votre environnement cloud
Les harnais de test sont particulièrement utiles pour les tests d'intégration qui valident les flux de travail sur plusieurs services, les end-to-end tests qui vérifient les parcours utilisateurs complets et les architectures axées sur les événements dans lesquelles les services communiquent via Amazon EventBridge SNS, Amazon SQS ou Amazon Kinesis.
## Organisez les environnements cloud pour isoler les développeurs
Les tests dans le cloud nécessitent des environnements isolés les uns des autres. Lorsque les développeurs partagent un compte unique Compte AWS, tel qu'un compte de développement d'équipe, envisagez de créer une pile d'applications distincte pour chaque développeur ou branche de fonctionnalité. Cela permet d'isoler les ressources, d'éviter les collisions de noms et d'éviter les conflits de quotas ou les problèmes de voisinage bruyants lors des tests.
Utilisez AWS Systems Manager le Parameter Store ou un outil similaire pour gérer les configurations spécifiques aux piles, telles que les points de terminaison d'API et les noms de files d'attente. Pour des raisons de rentabilité, partagez des ressources coûteuses telles que les clusters Amazon Relational Database Service (Amazon RDS) entre les équipes de développeurs tout en maintenant les ressources légères sans serveur (telles que les fonctions Lambda, les stages API Gateway et les tables DynamoDB) isolées par pile.
Dans les secteurs réglementés, les politiques de sécurité des entreprises peuvent restreindre l'accès des développeurs aux environnements cloud, ce qui complique l'exécution de tests cloud dans le cadre d'un flux de travail de développement local. Dans ces cas, les tests d'émulation peuvent combler le vide entre les tests simulés locaux et la validation complète dans le cloud, mais ils doivent être complétés par des tests dans le cloud chaque fois que l'accès le permet.
## Accélérer les boucles de rétroaction
Lorsque vous effectuez des tests dans le cloud, utilisez les outils et les techniques qui vous permettent d'accélérer les boucles de rétroaction de développement. Par exemple, utilisez le mode [AWS SAM Accelerate](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/accelerate.html) et le mode AWS CDK Watch pour réduire le temps nécessaire pour transférer les modifications de code vers un environnement cloud. Les exemples du [référentiel GitHub Serverless Test Samples](https://github.com/aws-samples/serverless-test-samples) explorent certaines de ces techniques.
Nous vous recommandons également de créer et de tester les ressources cloud à partir de votre machine locale le plus tôt possible pendant le développement, et pas seulement après l'enregistrement auprès du contrôle de source. Cette pratique permet d’accélérer l’exploration et l’expérimentation lors du développement de solutions. En outre, la possibilité d'automatiser le 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 à l'approbation des modifications du contrôle de source.