Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Debugging Microservices With Contract Testing

DZone 's Guide to

Debugging Microservices With Contract Testing

This method of contract testing focuses on the consumer and producer.

· Performance Zone ·
Free Resource

Image title

Sign your contract tests on the dotted line.

Microservices architecture has made tremendous changes to how we develop our software applications. Higher granularity in microservices is exposing boundaries that were previously hidden. This requires testers to employ a different mindset and strategies for successful debugging of microservices.

On that note, one strategy that we find particularly useful is contract testing. In this article, we'll discuss how contract testing works for microservices. When a consumer couples to the interface of a component to make use of its behavior, a contract is formed between them.

You may also enjoy: Improve Microservice Testing With Contract Testing

If it's a contract, it should have some exchange between the two parties. What do the consumer and component exchange? Its input and output data structures, side effects and performance and concurrency characteristics.

In this case, the component is microservice, so the interface would be an API exposed by each consuming service.

One of the basic properties of a microservices architecture is that microservices represents a unit of encapsulation. There is a contract through the API between each service and contract testing reveals different languages, stack, and patterns between each service.

As a tester, you have to write an independent test suite that verifies only those aspects of producing services that are in use. Consider this topology, an example of microservice architecture.


microservices architecture example

Here, service A is talking to Service B, and this architecture also involves service B talking to Redis and service C. In the contract test, we would only test the smaller unit, that is, service A’s interaction with service B. And we will do this by creating a fake for service B and testing A’s interaction with the fake.

Service A also talks with Riak. In this case, the smallest unit to be tested would be the communication between service A and Riak.

According to , contract testing consist of three steps.

  • “As a consumer of an API, you write a “contract.” This contract states what you expect from the provider (of an API). Based on this contract generates a mock of the provider.
  • As a consumer, you can test your own application against the mock of the provider.
  • The contract can be sent over to the provider who can validate if the actual implementation matches the expectations in the contract.”

He says that the contract test fits well into a microservices workflow and that’s why it’s awesome. Groeneweg talks about some anti-patterns in contract testing.

These are:

  • Contract test is beneficial to best fit the consumer’s wishes, but sometimes it moves from consumer-driven to consumer-dictated.
  • Writing a contract test before having a good face-to-face discussion is a bad idea. This also applies to doing feature requests before contract tests.
  • Typical scenarios such as zero result or failed authentication are quickly overseen. This should be avoided through proper coverage.
  • Only create a contract test for what you need. This gives the provider more freedom to change and optimize his service.

Let’s consider a situation wherein a consumer demands a specific combination of fields in response. For this to work, the provider team has to go across databases, which will make it hard to implement them. Even if they implement it, the solution will be very slow and everyone will be frustrated. This is called consumer-dictated contract testing.

The best solution would be to cooperate on the contract and find the solution which works best for everyone. I recommend this website for some useful resources on contract testing.

Conclusion

My goal was not to make an argument for one form of testing over others but to showcase the lessons our team has learned while implementing microservices testing strategies. There may be things that may not resonate with you because every scenario differs.

In a nutshell, contract testing is one you need to incorporate in your comprehensive release process. Also, performance contract test is a combination of other tests such as automated unit testing, integration testing and load testing combined with the manual. This will provide you the overall quality assurance in the process.

Today most large enterprises such as Netflix, Amazon, and Uber have moved towards microservice, which makes microservice testing more imperative. If you have any suggestions, questions or if you are struggling to execute a successful microservices testing pipeline, feel free to contact me or leave a comment below.

Further Reading

Encapsulation in Java

Best Practices for Tracing and Debugging Microservices

Topics:
microservice architecture ,serverless applications ,software testing ,contract testing ,microservice best practices ,microservices debugging ,producer ,consumer ,performance

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}