Contract testing is a great technique that provides a reliable way to verify the agreed boundaries between your microservices without all the complexity of integration testing.
It has some steep learning curve though. The following post covers some of the technical challenges my team had to overcome when introducing the Pact-based contract testing into our Java microservices world.
Which DSL variant shall I use for my Java project?
Java, Java 8 with lambdas, or Groovy DSL — which one is the best? That’s the exact question we asked ourselves before jumping into the world of pacts.
Let’s have a look at an example of JSON structure specified using different JVM DSLs. I’m going to use a product definition you might find in a typical warehouse system, with the following…
Have you ever verified your integration with an external service using a mocked response, only to realize later that things work quite differently in a production environment? If only you knew some approach to ensure mocks are just fine and up to date, right?
Cue contract testing to the rescue!
Introduction
Distributed systems these days are complex, there’s no doubt about that. With more and more moving parts — new services being created, old services being deprecated, new API versions published, or existing API versions being extended — it’s difficult to keep up with the changes. …
Learn how to make the best out of contract testing by using Pact Broker and can-i-deploy tools in your build & deployment pipelines.
Pact Broker
The Pact Broker is an open-source tool that allows you to share your pacts and store the results of their verification. You may treat it as a repository of your published contracts together with their testing report.
Pact publishing
In order to see your pact on Pact Broker pages, you need to publish it first. Pact contract testing follows the consumer-driven approach, which means it’s the consumer who creates a contract defining new requirements against the provider API.
As a part of her build — optionally for feature branches and, ideally, always for the main branch— the consumer runs tests that create pacts (i.e. using Groovy DSL), and later triggers their publication to Pact Broker. …
Code review has become an essential practice for many programmers. It comes with a variety of great outcomes, just to name a few:
- it’s a way to improve the quality of your codebase,
- it helps introducing the coding standards in your team or company,
- it can easily boost knowledge within your team,
- it allows junior developers to learn from seniors,
- it allows senior developers to make use of a fresh perspective of a junior.
But the question is, what makes a great code reviewer? How to conduct a review to make the best out of it?
Even though code reviews are widely used in almost all IT companies these days, there are some do’s and don’ts I find not so popular. In the following sections I gathered the best and worst practices I’ve seen in my day-to-day…
About
