For Microservices-specific tests, read Manning's Testing Java Microservices for a summary, other miscellaneous impressions, reference tools and announcements, etc. I tried to write in a row. This book is MEPA (book in progress) and is by V13. Please note that at this time all chapters seem to be written and there may be revisions to each part.
Also, please be aware that it is quite complicated because it is based on what was originally written in-house.
Testing Java Microservices
Chapter1
I will skip it because it is only an overview explanation
Chapter2
There is no story specific to Microservices. Descriptions of Test Double, Mock, Stab, etc.
Chapter 3
Omitted because it is about Unit Test. Tools are also a general Unit Test story.
Chapter 4
Component Test chapter. Since Arquillian is used, the test execution will be performed with the application actually running.
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.
That's right.
As for the dependency, the actual one is used for the application part except DB. (DB is directed to the test DB)
After that, you can get Request / Response with the REST test framework provided by Arquillian, so write a test to see if Request / Response is as intended. (p90) In the chapter headings, the test target is divided into the following.
Description of each
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.
It seems that it is a test that combines the classes that actually depend on it within the subsystem (probably a single REST API implementation). Externally dependent parts are not subject to testing, but make sure you can communicate. This chapter is the main part of the test using DB. If you read back the Persistence component in Chap4, see Chap5 for details.
Important things in integration testing (p109)
The Persistence test seems to have Arquillian Persistence. https://docs.jboss.org/author/display/ARQ/Persistence?_sscc=t http://kikutaro777.hatenablog.com/entry/2013/01/06/233526 It seems to be more abstract and convenient than DbUnit. Since Arquillian is for JavaEE, it seems better to check if it can be used with persistence platforms other than JavaEE.
Contract Test
Contract confirmation. Check if the API contract is protected. API compatibility verification.
You can do it with Integration Test, but there is a problem.
The first one is that the consumer must know how to boot up the provider.
The consumer must know how to start the provider.
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.
The second point is that consumers may depend on several providers. Both providers have different requirements. For example, a database or another service. So starting a provider means starting some services, which can mean unnoticed converting integration tests to end-to-end tests (with some machine translation).
The third problem and most important one is that you need to create a direct relationship between producer and all its consumers.
With the current movement (Note: the company I belong to at that time), it seems that the granularity of Service is large and it is unlikely that it will depend on complicated things (services associated with specific things), so Contract Test may not be very important. It is necessary to confirm that the contract is protected, but since the dependency mesh is unlikely to be complicated, writing a test normally may not increase the cost.
The following classifications can be made from the viewpoint of where the contracting entity is.
Producer from the general Consumer point of view of Contract Test seems to be Mock. http://techlife.cookpad.com/entry/2016/06/28/164247 Is it really a formal check of request and response? Such a Request returns such a Response. On the Consumer side, apart from the detailed contents of Request, the type of Response is different for each Endpoint and it is verified whether it is the intended one.
It's not Functional, so it looks good.
Read the description of the tool for realizing Consumer Driven Contract called 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.
It seems to be effective only for APIs that can be controlled by their organization.
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?
The Scala version of Pact is the following two.
https://github.com/ITV/scala-pact https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-consumer-specs2
It seems that the language should be selected according to the Consumer implementation.
As a Consumer implementation, it seems better not to receive it because there is an API return value of Provider. Narrow down to what you need. Otherwise, Porvider will be bloated.
DeNA Okita's material. I had heard this, but I forgot.
https://speakerdeck.com/okitan/microservicesniokeruapizi-dong-tesutonimatuwaruetosetora
It is written specifically for Spec inspection for REST API. Mainly JSON Schema instead of Swagger. JSON Schema is certainly good in terms of response type, but in the opinion of a former colleague, it is expensive. Well because it's a PoC. Whether or not to use JSON Schema during actual development may also be an issue to be considered.
According to a story from a former colleague, there is also a test to create a scenario with REST API and run it without going through the UI. It may certainly be in the sense of confirming the data flow by API, excluding the dynamic change part by UI from the test target. It will be overwhelmingly easier to implement and create than via the UI. It is necessary to consider the part where this method is effective.
By the way, I remembered that I used to set up a scenario test to verify the validity at the API level with JMeter.
packt-jvm
https://www.slideshare.net/setoazusa/pact-for-jvm A slide about the Pact-jvm.
The Contract File output by pact seems to have all fields by default. That's right. You can't tell which of the Responses you actually need until you implement the Consumer.
It seems necessary to manually trim the Contract File output by pact.
Recommended Posts