When I joined Automobilmart, the team had great API tests but zero contract coverage. Writing Pact interactions by hand was tedious, error-prone, and nobody was doing it consistently.
The Problem
Contract testing is one of those practices everyone agrees is valuable but rarely implements well. The barrier is the authoring overhead — writing Pact interactions requires understanding both the consumer expectations AND the provider API shape, then expressing that in Pact's DSL. For a team already maintaining E2E suites, API tests, and BDD scenarios, it was just another thing to not get done.
The Insight
The insight came from looking at our existing Axios-based API test suite. We already had hundreds of test calls with explicit assertions on response shape, status codes, and field types. The data was *already there* — we just weren't packaging it as contract definitions.
What Smart Pact Does
Smart Pact intercepts your existing API test calls, captures the request/response pairs, and auto-generates valid Pact interaction files that you can push to your Pact Broker. It works with any Jest + Axios test suite without requiring you to change a single line of your existing tests.
import { SmartPact } from 'smart-pact';
const pact = new SmartPact({
consumer: 'PaymentConsumer',
provider: 'PaymentAPI',
outputDir: './pacts'
});
// Your existing test — unchanged
it('creates a payment link', async () => {
const response = await axios.post('/api/payments/link', payload);
expect(response.status).toBe(201);
expect(response.data).toHaveProperty('paymentUrl');
});Smart Pact generates the Pact file automatically from this interaction.
The Result
At Automobilmart, we went from zero contract coverage to full payment API contract validation in one sprint — without touching any existing test code. The library is now on npm and being used in production CI/CD pipelines.
The lesson: the best tools remove friction from practices that teams already believe in but struggle to implement.
Emmanuel Eko
SDET & QA Architect