Für Microservices-spezifische Tests lesen Sie Mannings Testen von Java Microservices für eine Zusammenfassung, andere verschiedene Eindrücke, Referenztools und Ankündigungen usw. Ich habe versucht, hintereinander zu schreiben. Dieses Buch ist MEPA (Book in Progress) und basiert auf V13. Bitte beachten Sie, dass zu diesem Zeitpunkt alle Kapitel geschrieben zu sein scheinen und es möglicherweise Überarbeitungen zu jedem Teil gibt.
Bitte beachten Sie auch, dass es ziemlich kompliziert ist, da es auf dem basiert, was ursprünglich im eigenen Haus geschrieben wurde.
Testing Java Microservices
Chapter1
Ich werde es überspringen, da es nur eine Übersichtserklärung ist
Chapter2
Es gibt keine spezifische Geschichte für Microservice. Beschreibungen von Test Double, Mock, Stab usw.
Chapter 3
Ausgelassen, weil es um Unit Test geht. Tools sind auch eine allgemeine Unit-Test-Geschichte.
Chapter 4
Kapitel Komponententest. Da Arquillian verwendet wird, wird der Test mit der tatsächlich ausgeführten Anwendung ausgeführt.
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.
Korrekt.
Mit Ausnahme von DB usw. verwendet der Anwendungsteil den tatsächlichen. (DB ist angewiesen, DB zu testen)
Danach können Sie Request / Response mit dem von Arquillian bereitgestellten REST-Testframework abrufen. Schreiben Sie daher einen Test, um festzustellen, ob Request / Response wie beabsichtigt ist. (S. 90) In der Kapitelüberschrift ist das Testziel wie folgt unterteilt.
Beschreibung von jedem
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.
Es scheint ein Test zu sein, der die tatsächlich davon abhängigen Klassen innerhalb des Subsystems kombiniert (wahrscheinlich eine einzelne REST-API-Implementierung). Extern abhängige Teile werden nicht getestet, aber stellen Sie sicher, dass Sie kommunizieren können. Dieses Kapitel ist auch der Hauptteil des Testens mit DB. Wenn Sie die Persistenzkomponente in Kapitel 4 zurücklesen, finden Sie Einzelheiten in Kapitel 5.
Wichtige Dinge beim Integrationstest (S. 109)
Der Persistenztest scheint eine arquillianische Persistenz zu haben. https://docs.jboss.org/author/display/ARQ/Persistence?_sscc=t http://kikutaro777.hatenablog.com/entry/2013/01/06/233526 Es scheint abstrakter und bequemer zu sein als DbUnit. Da Arquillian für Java EE ist, ist es besser zu prüfen, ob es mit anderen Persistenzplattformen als Java EE verwendet werden kann.
Contract Test
Vertragsbestätigung. Überprüfen Sie, ob der API-Vertrag geschützt ist. Überprüfung der API-Kompatibilität.
Dies kann mit dem Integrationstest durchgeführt werden, es liegt jedoch ein Problem vor.
The first one is that the consumer must know how to boot up the provider.
Der Verbraucher muss wissen, wie er den Anbieter startet.
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.
Der zweite Punkt ist, dass Verbraucher von mehreren Anbietern abhängig sein können. Beide Anbieter haben unterschiedliche Anforderungen. Zum Beispiel eine Datenbank oder ein anderer Dienst. Das Starten eines Anbieters bedeutet also das Starten einiger Dienste und kann das unbemerkte Konvertieren von Integrationstests in End-to-End-Tests (mit einigen maschinellen Übersetzungen) bedeuten.
The third problem and most important one is that you need to create a direct relationship between producer and all its consumers.
Bei der aktuellen Bewegung (Hinweis: das Unternehmen, zu dem ich zu dieser Zeit gehörte) bin ich der Meinung, dass die Granularität des Service groß ist und es unwahrscheinlich ist, dass er von komplizierten Dingen abhängt (Services, die mit bestimmten Dingen verbunden sind), sodass der Vertragstest möglicherweise nicht sehr wichtig ist. Es muss bestätigt werden, dass der Vertrag geschützt ist. Da es jedoch unwahrscheinlich ist, dass das Abhängigkeitsnetz kompliziert ist, erhöht das Schreiben eines Tests normalerweise nicht die Kosten.
Die folgenden Klassifizierungen können unter dem Gesichtspunkt vorgenommen werden, wo sich der Auftraggeber befindet.
Der Hersteller aus der Sicht des allgemeinen Verbrauchers von Contract Test scheint Mock zu sein. http://techlife.cookpad.com/entry/2016/06/28/164247 Ist es wirklich eine formelle Überprüfung der Anfrage und Antwort? Eine solche Anfrage gibt eine solche Antwort zurück. Auf der Verbraucherseite ist die Art der Antwort, abgesehen vom detaillierten Inhalt der Anforderung, für jeden Endpunkt unterschiedlich und es wird überprüft, ob es sich um den beabsichtigten handelt.
Es ist nicht funktional, sieht also gut aus.
Lesen Sie die Beschreibung des Tools zur Realisierung eines verbraucherorientierten Vertrags mit dem Namen 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.
Es scheint nur für APIs wirksam zu sein, die von ihrer Organisation gesteuert werden können.
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?
Die Scala-Version von Pact ist die folgende zwei.
https://github.com/ITV/scala-pact https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-consumer-specs2
Es scheint, dass Sie die Sprache entsprechend der Consumer-Implementierung auswählen sollten.
Als Implementierung von Consumer scheint es besser, es nicht zu empfangen, da es einen API-Rückgabewert von Provider gibt. Grenzen Sie ein, was Sie brauchen. Andernfalls wird Porvider aufgebläht.
DeNA Okitas Material. Ich hatte das gehört, aber ich habe es vergessen.
https://speakerdeck.com/okitan/microservicesniokeruapizi-dong-tesutonimatuwaruetosetora
Es wurde speziell für die Spezifikationsprüfung für die REST-API geschrieben. Hauptsächlich JSON-Schema anstelle von Swagger. JSON Schema ist sicherlich gut in Bezug auf den Antworttyp, aber nach Meinung eines ehemaligen Kollegen ist es teuer. Nun, weil es PoC ist. Es kann auch ein zu berücksichtigendes Problem sein, ob das JSON-Schema während der tatsächlichen Entwicklung verwendet werden soll oder nicht.
Laut einer Geschichte eines ehemaligen Kollegen kann es einen Test geben, bei dem ein Szenario mithilfe der REST-API erstellt und ausgeführt wird, ohne die Benutzeroberfläche zu durchlaufen. Dies kann sicherlich im Sinne einer Bestätigung des Datenflusses durch die API erfolgen, wobei der Teil der dynamischen Änderung durch die Benutzeroberfläche vom Testziel ausgeschlossen wird. Die Implementierung und Erstellung ist überwiegend einfacher als über die Benutzeroberfläche. Es ist notwendig, den Teil zu berücksichtigen, in dem diese Methode wirksam ist.
Ich erinnerte mich übrigens daran, dass ich früher einen Szenariotest eingerichtet hatte, um die Gültigkeit auf API-Ebene mit JMeter zu überprüfen.
packt-jvm
https://www.slideshare.net/setoazusa/pact-for-jvm Eine Folie über Pact-jvm.
Die von pact ausgegebene Vertragsdatei scheint standardmäßig alle Felder zu haben. Korrekt. Sie können nicht wissen, welche Antwort tatsächlich benötigt wird, ohne Consumer zu implementieren.
Es scheint notwendig, die Ausgabe der Vertragsdatei per Pakt manuell zu kürzen.
Recommended Posts