Using Pact and Quarkus to Tame Microservices Testing

Even when developing, standing up all the dependencies and consumers for an individual microservice can be hard work. Recently, our consulting colleagues received a plea for help from the CTO of a tech startup, who couldn’t run his dev stack on a brand new laptop with 64 GB of RAM, because the application involved dozens of microservices and they consumed so many resources. (If this sounds familiar, Quarkus can help lower the resource consumption of the stack, but that’s a different topic!)

Teams sometimes address the challenge of local microservices development by providing remote environments into which local code can be injected. This is sometimes called "remocal development" or telepresence. Another, purely local, model, is local virtual environments.

While these environments can be useful, they can also be fragile, and managing them often needs a dedicated platform team.

When having 'real' versions of the rest of the system to test against is too heavy, teams often use mocks or stubs. (Mocks and stubs are subtly different, but for simplicity I’ll use "mocks" to describe both.) Mocks have many advantages; they’re lightweight and enable unit testing of code with external dependencies. However, mocks also have a big disadvantage; there’s no guarantee the mock behaves like real the thing. Users of a service will bake their own assumptions about how a service behaves into a mock. If a service changes, it’s up to consuming code to figure out what’s changed and update the mocks.

Sometimes, the first time these assumptions are tested is in production.

How can we make a link between the mock being used by a consumer, and the functional validation being done by the provider? This is where contract testing helps. A contract testing framework powers two things:

With Test Driven Development(TDD), you start with tests (a description of the desired behaviour) and work backwards to an implementation. You can do the same thing with contract testing; you start with the contract, which describes what the service needs to do, and work backwards to the implementation. This is known as "contract-first", and it can be a very effective development technique. My colleagues in Red Hat App Dev Consulting have written some great articles about how they use contract-first development.

There are a few different contract-testing frameworks out there, including Pact, Microcks, Spring Cloud Contract. Some teams also build up their own OpenAPI-based toolchains, such as Schemathesis for functional tests, and Prism for the mocking. Arguably the most popular contract testing solution is Pact, so it’s where the Quarkiverse support for contract testing has started.

The Pact team have a good overview of the advantages and disadvantages of schema-based testing (such as validation based on an OpenAPI spec) and contract testing.

Using Pact with Quarkus isn’t new; Quarkus contributors made several classloading adjustments in Quarkus core to support Pact testing in Quarkus 2.0, but this support was limited. In particular, Pact tests couldn’t run in continuous testing mode.

Quarkus 3.0 moves Pact support from Quarkus core to its own Quarkiverse extension, where it can be deeper. Quarkus core also includes classloading changes in the Kotlin extension and some classloading fixes in continuous testing itself. These mean that, with the Pact Quarkiverse provider and consumer extensions Pact tests work properly with quarkus test and quarkus dev.

To install the consumer extensions, run

The provider extension can be installed with

For a deeper dive into contract testing, check out Quarkus Insights #117.

If you’re using microservices, you should seriously consider contract testing. With the new Pact extension, Quarkus 3 allows contract tests to be developed using the same great workflow as other tests.