Along with unit and integration testing, contract testing should have its place in the testing pyramid. The autochanger client retrieves all available books from the /books library server endpoint. When integrating for the client, we use a book server stub, which we automatically generate with Spring Cloud Contract to guarantee the API contract: Fortunately, Spring Cloud Contract also supports the Pact contract format. To automatically generate tests from a Pact file, you need to place the Pact file (which is a JSON file) in the src/test/contracts folder and add these dependencies to your build.gradle: Note that the DSL contract allows you to specify matchers instead of static content, so the username defined in our contract does not necessarily have to be « Arthur Dent », but can be, for example, any string. What you`ve done so far is an iterative process. You can play with the contract, install it locally and work on the consumer`s side until the contract works as intended. In the consumer-centric contract testing approach, consumers offer contracts in close collaboration with manufacturers. These contracts are usually stored in a producer repository or in a trade repository that consumers and producers can access. Spring Cloud Contract uses a framework called Rest Assured to send and receive test REST requests. Rest Assured includes an API that follows behavior-driven development best practices.
The test is descriptive and all request and response entries defined in the contract have been successfully referenced. Why do we need the base class? In this example, we create a contract test that ensures that a GET call to /books returns the data specified as application/json with an HTTP 200 state. Therefore, we create a file shouldReturnBooks.groovy and explain the contract: as stated above, consumer-oriented contracts can be specified in any available way, e.B. in Groovy DSL, YAML, PACT JSON, Spring Rest Docs. The following example shows the contract written in Groovy: For more information about consumer-oriented contracts with Spring Cloud Contract, see the following resources: This article focuses on the vendor page. A consumer of our API has created a contract in advance and we want to verify that the REST API provided by our Spring Boot service meets the expectations of this contract. Let`s go back to the main problem – client-server communication integration tests. Are we required to use handwritten HTTP/messaging stubs and coordinate changes with their producers? Or are there better ways to solve this problem? Let`s take a look at a contract test and how they can help us. The contract indicated above is an agreement between two parties: you set up two microservices, one of which provides its contract and the other consumes this contract to ensure that the integration with the service of the contractual provider complies with the specifications. In the future, if the manufacturer`s service contract changes, consumer service testing will not detect the potential incompatibility. In the last part, I briefly introduced the concept of contract testing and why we need it. This article describes how to use the Spring Cloud contract to enforce contract tests between Spring Boot microservice applications.
Each contract defines a unique request/response pair. The above contract defines an API provided by the user service, which consists of a POST request to the URL /user-service/users that contains user data in the body of the text, and an expected response to that request that returns the HTTP code 201 and the newly created user`s database ID as text. To verify an API provider (in our case, the Spring Controller), Spring Cloud Contract automatically generates JUnit tests from a specific contract. To give these automatically generated tests a working context, we need to create a base test class that is subclassified by all the generated tests: you can start playing with the server-side contract. To do this, you must first clone it. For HTTP stubs, a contract defines the type of response to be returned for a particular request (taking into account HTTP methods, URLs, headers, status codes, and so on). The following example shows how to create an HTTP stub contract in Groovy DSL: Congratulations! You have just used Spring to have your REST Services declare your contract and bring the Consumer Service into compliance with this Agreement. By extracting the producer repository, adding contracts, and generating the stubs by running the following commands: Place the contract in the src/test/resources/contracts/fraud folder. The scam folder is important because the name of the manufacturer`s test base class points to this folder. Instead of testing consumers and API providers end-to-end, with consumer-focused contract testing, we divide our API testing into two parts: For more in-depth content and guidance on testing Spring Boot applications, you need to sign up for the Spring Boot Applications Testing masterclass. .