Pour les tests spécifiques aux microservices, lisez [Testing Java Microservices] de Manning (https://www.manning.com/books/testing-java-microservices) pour un résumé, d'autres impressions diverses, des outils de référence et des annonces, etc. J'ai essayé d'écrire dans une rangée. Ce livre est MEPA (livre en cours) et est basé sur V13. Veuillez noter que pour le moment, tous les chapitres semblent être écrits et il peut y avoir des révisions à chaque partie.
De plus, sachez que c'est assez compliqué car il est basé sur ce qui a été initialement écrit en interne.
Testing Java Microservices
Chapter1
Je vais l'ignorer car ce n'est qu'une explication d'ensemble
Chapter2
Il n'y a pas d'histoire spécifique à Microservice. Descriptions de Test Double, Mock, Stab, etc.
Chapter 3
Omis car il s'agit du test unitaire. Les outils sont également une histoire générale de test unitaire.
Chapter 4
Chapitre Test des composants. Puisque Arquillian est utilisé, le test sera exécuté avec l'application en cours d'exécution.
Component tests should be designed to verify the functionality of, and between, the internal modules of a microservice, with one exception. The external public facing resource component.
C'est vrai.
À l'exception de la base de données, etc., la partie application utilise la partie réelle. (DB est dirigé pour tester DB)
Après cela, vous pouvez obtenir Request / Response avec le framework de test REST fourni par Arquillian, alors écrivez un test pour voir si Request / Response est comme prévu. (p90) Dans l'en-tête du chapitre, la cible du test est divisée comme suit.
Description de chacun
Summary
Integration Test
Integration tests check the interactions between different modules (or classes), usually belonging to the same subsystem, in order to verify that they collaborate as expected when providing a high level feature.
Cela semble être un test qui combine les classes qui en dépendent réellement dans le sous-système (probablement une seule implémentation d'API REST). Les pièces dépendantes de l'extérieur ne sont pas soumises à des tests, mais assurez-vous de pouvoir communiquer. Ce chapitre est la partie principale du test utilisant DB. Si vous relisez le composant Persistence dans Chap4, voir Chap5 pour plus de détails.
Éléments importants dans les tests d'intégration (p109)
Le test de persistance semble avoir une persistance arquillienne. https://docs.jboss.org/author/display/ARQ/Persistence?_sscc=t http://kikutaro777.hatenablog.com/entry/2013/01/06/233526 Cela semble être plus abstrait et pratique que DbUnit. Comme Arquillian est pour Java EE, il semble préférable de vérifier s'il peut être utilisé avec des plates-formes de persistance autres que Java EE.
Contract Test
Confirmation du contrat. Vérifiez si le contrat API est protégé. Vérification de la compatibilité des API.
Cela peut être fait avec le test d'intégration, mais il y a un problème.
The first one is that the consumer must know how to boot up the provider.
Le consommateur doit savoir comment démarrer le fournisseur.
The second one is that consumer might depend on several providers. Each provider might have different requirements, for example a database or other services. So starting a provider can imply to start several services and without noticing it converting the integration tests into end-to.end tests.
Le deuxième point est que les consommateurs peuvent dépendre de plusieurs fournisseurs. Les deux fournisseurs ont des exigences différentes. Par exemple, une base de données ou un autre service. Donc, démarrer un fournisseur signifie démarrer certains services et peut signifier la conversion inaperçue des tests d'intégration en tests de bout en bout (avec une traduction automatique).
The third problem and most important one is that you need to create a direct relationship between producer and all its consumers.
Avec le mouvement actuel (Note: l'entreprise à laquelle j'appartenais à ce moment-là), je pense que la granularité du Service est grande et il est peu probable que cela dépendra de choses compliquées (services associés à des choses spécifiques), donc le Contrat Test peut ne pas être très important. Il est nécessaire de confirmer que le contrat est protégé, mais comme il est peu probable que le maillage de dépendances soit compliqué, l'écriture d'un test ne peut normalement pas augmenter le coût.
Les classifications suivantes peuvent être faites du point de vue de l'endroit où se trouve l'entité adjudicatrice.
Le producteur du point de vue général du consommateur de Contract Test semble être Mock. http://techlife.cookpad.com/entry/2016/06/28/164247 S'agit-il vraiment d'un contrôle formel de la demande et de la réponse? Une telle demande renvoie une telle réponse. Du côté du consommateur, mis à part le contenu détaillé de la demande, le type de réponse est différent pour chaque point de terminaison et il est vérifié si la réponse prévue est correcte.
Ce n'est pas fonctionnel, donc ça a l'air bien.
Lisez la description de l'outil de réalisation de contrat axé sur le consommateur appelé https://github.com/realestate-com-au/pact.
What is it good for? Pact is most valuable for designing and testing integrations where you (or your team/organisation/partner organisation) control the development of both the consumer and the provider, and the requirements of the consumer are going to be used to drive the features of the provider. It is fantastic tool for developing and testing intra-organisation microservices.
Il semble être efficace uniquement pour les API qui peuvent être contrôlées par leur organisation.
What is it not good for?
* Testing new or existing providers where the functionality is not being driven by the needs of the consumer (eg. public APIs)
* Testing providers where the consumer and provider teams do not have good communication channels.
* Performance and load testing.
* Functional testing of the provider - that is what the provider's own tests should do. Pact is about checking the contents and format of requests and responses.
* Situations where you cannot load data into the provider without using the API that you're actually testing (eg. public APIs). Why?
* Testing "pass through" APIs, where the provider merely passes on the request contents to a downstream service without validating them. Why?
La version Scala de Pact est la suivante.
https://github.com/ITV/scala-pact https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-consumer-specs2
Il semble que vous deviez choisir la langue en fonction de l'implémentation Consumer.
En tant qu'implémentation de Consumer, il semble préférable de ne pas le recevoir car il existe une valeur de retour API de Provider. Limitez-vous à ce dont vous avez besoin. Sinon, Porvider sera gonflé.
Matériel de DeNA Okita. J'avais entendu cela, mais j'ai oublié.
https://speakerdeck.com/okitan/microservicesniokeruapizi-dong-tesutonimatuwaruetosetora
Il est écrit spécifiquement pour l'inspection des spécifications pour l'API REST. Principalement le schéma JSON au lieu de Swagger. JSON Schema est certes bon en termes de type de réponse, mais de l'avis d'un ancien collègue, c'est cher. Eh bien parce que c'est PoC. L'utilisation ou non du schéma JSON pendant le développement réel peut également être un problème à prendre en compte.
Selon une histoire d'un ancien collègue, il existe également un test pour créer un scénario avec l'API REST et l'exécuter sans passer par l'interface utilisateur. Cela peut certainement être dans le sens de confirmer le flux de données par API, en excluant la partie de changement dynamique par UI de la cible de test. Il sera extrêmement plus facile à mettre en œuvre et à créer que via l'interface utilisateur. Il faut considérer la partie où cette méthode est efficace.
Au fait, je me suis souvenu que j'avais l'habitude de mettre en place un test de scénario pour vérifier la validité au niveau de l'API avec JMeter.
packt-jvm
https://www.slideshare.net/setoazusa/pact-for-jvm Une diapositive sur Pact-jvm.
La sortie du fichier de contrat par pact semble avoir tous les champs par défaut. C'est vrai. Vous ne pouvez pas savoir quelle réponse est réellement nécessaire sans implémenter Consumer.
Il semble nécessaire de couper manuellement la sortie du fichier de contrat par pacte.
Recommended Posts