Skip to content

Work

Contract tests across services

Consumer-driven checks that catch breaking API changes in the pipeline.

Situation

Uvion Tech ships software as a set of services. A schema change in one of them can break the others before the failure ever shows up in a browser. I joined as an SDET in March 2025 to put those checks closer to the change.

What I built

I built a consumer-driven contract testing framework, and I still maintain it today. The suite validates API schemas and catches breaking integration changes between services. Around it, I design API and web test cases in TestRail and Zephyr, and I write API automation in Java with JUnit and in Ruby with HTTParty.

How it ran

The contract checks run in Jenkins, in the same pipeline as the rest of the automated tests. When a build fails I trace whether the cause is the product, the test, or the pipeline, and I log the defect with enough detail for the person who owns the service.

What changed

Breaking changes between services show up in CI, while the change is still cheap to undo. The same release still gets functional, integration, and regression testing, on both the microservices and the monolithic parts of the product.

What I would change

I would fail the producer build itself when a contract breaks, so the service that changed the schema is the one that stops.