In the previous post, checkout’s test suite generated a real contract file describing two interactions with the payment service, an authorized payment and a declined one. That file sitting in target/pacts proves nothing about payment’s actual behavior yet. This post covers the other half of Pact, taking that same file and replaying it against payment’s real implementation. Adding the Provider Dependency On the payment service side, add Pact’s provider JVM module. ...

In the previous post, we added the Pact JVM dependency and sketched out a contract definition for authorizing a payment. That definition on its own does not generate anything yet. We still need a test method that actually exercises it, by calling real client code against Pact’s mock server. That is what turns a description of an interaction into a generated contract file on disk. Connecting the Test to the Mock Pact’s JUnit 5 extension injects a MockServer into your test method, giving you the actual host and port the mock is running on. Your job is to point your real HTTP client at that address instead of the real payment service. ...

In the previous post, we covered why contract testing exists and where Pact fits between unit tests and full integration tests. Before we can write an actual contract, we need Pact wired into the project. This post is the setup step, getting a Spring Boot service ready to generate its first contract. Adding the Dependency Pact JVM ships a JUnit 5 module that plugs straight into the test framework you are probably already using. For a Maven project, add this to the checkout service’s pom.xml. ...

Every team running more than a handful of microservices eventually hits the same wall. Integration tests that spin up three or four real services are slow and flaky. End-to-end tests that go through the whole system catch real problems, but only after everything is already deployed, and a single unrelated service being down fails the whole suite. Somewhere in between those two extremes sits a much cheaper question. Does my service still honor what the other services expect from it. ...

As I’ve been leaning heavier into AI-assisted coding and scripting for my own side projects over the past year, my API token usage shot up fast—it went from a cheap experiment to an invoice that made me do a double-take. Lately, my focus has been all about Token Optimization, Context Caching, and keeping my setup lean. Things I’ve Been Tweaking 1. Prompt Caching & Smart Context Truncation When OpenAI and Anthropic rolled out prompt caching, I jumped on it immediately for my personal scripts. By caching heavy system prompts, common schemas, and reusable code patterns, I managed to slash my monthly LLM API spend by over 45% while actually speeding up execution times. ...

With multimodal models like GPT-4 Vision and Claude 3 Opus getting so much sharper, test automation is finally moving beyond fighting with the HTML DOM and into actual Visual and Spatial Verification. Things I’ve Been Experimenting With 1. Screenshot-Based Visual Assertions In the past, visual testing meant wrestling with rigid pixel-by-pixel diff tools that would blow up your build over a tiny font rendering shift. Lately, I’ve been feeding raw UI screenshots directly to vision-capable LLMs along with plain English questions: “Is the checkout button properly aligned below the order summary? Is any text overlapping?” ...

Flaky tests caused by shifting DOM element IDs have been the bane of my existence for as long as I’ve been writing test automation. I got tired of constant pipeline failures over minor UI tweaks, so lately I’ve been tinkering with Runtime Self-Healing Mechanisms directly inside my Playwright test runners. What I’ve Been Building Recently 1. Dynamic Selector Healing I set up dynamic error interceptors inside my test suites. When a locator lookup fails (say, a TimeoutError: element '#submit-order-v2' not found), the test runner catches the exception, snags a snapshot of the surrounding DOM tree, and hands it off to an LLM to request an alternative CSS or XPath selector. ...

In the previous post, we got a large suite running fast in CI. This is the last post in the series, and it covers something that matters more the longer a framework lives. Keeping it healthy after the initial build is done. A framework that looks clean on day one can turn into a mess after six months of multiple people adding tests under deadline pressure. Inconsistent formatting, selectors that break constantly, tests nobody trusts anymore. None of this is really a Playwright problem. It is a team habits problem, and it is solvable with the right tooling in place from early on. ...

In the previous post, we got our suite running automatically in GitHub Actions. That works fine when you have thirty tests. It starts to feel slow once you have three hundred. Today we look at getting that feedback loop back down to something reasonable. There are two separate levers here, and it is worth understanding the difference. Workers control how many tests run at once on a single machine. Sharding controls splitting the whole suite across multiple separate machines entirely. You usually want both. ...

In the previous post, we set up reporting and traces so failures are easy to diagnose. None of that matters much if tests only run on your own laptop. Today we wire everything into a CI pipeline, so every pull request gets tested automatically before it can be merged. We will use GitHub Actions here, since it is what most teams already have available, and Playwright has solid first party support for it. ...