In the previous post, we sped up tests by mixing in API calls. Today we cover something every team hits eventually. A test fails overnight in CI, nobody was watching it run, and now someone has to figure out why. This used to mean staring at a stack trace and a screenshot, if you were lucky enough to have a screenshot at all, and guessing at what the page must have looked like. Playwright gives you a lot more to work with than that, and it is worth setting all of it up before you actually need it. ...

Entering 2024, it feels like the whole AI tooling ecosystem has leveled up dramatically over the last year. We’re finally moving past hacky string parsing and regex workarounds—OpenAI’s native Function Calling has completely changed how I build scripts that interact with LLMs. What I’ve Been Experimenting With Lately 1. Reliable, Deterministic Scripting via Function Calling Instead of asking the model for raw code or text and hoping for the best, I’ve been defining strict JSON schemas for core test actions—things like click_element(selector), fill_input(selector, text), and assert_text(expected). ...

In the previous post, we looked at why Playwright tests do not need manual sleeps. Today we look at a different kind of speed problem. Tests that spend most of their time on setup steps that have nothing to do with what they are actually testing. Say you are testing the checkout flow. To get there, a real user has to log in, search for a product, add it to the cart, and then go to checkout. If every single checkout test drives all of that through the UI first, you are spending most of your test run clicking through steps you already tested thoroughly somewhere else. That adds up fast across a whole suite. ...

In the previous post, we used fixtures to clean up test setup. Today we talk about the thing that probably causes more wasted engineering hours than anything else in test automation. Flakiness. If you have worked with older browser automation tools, you know the pattern. A test fails intermittently. Someone adds sleep(2000) right before the failing step. The test passes for a while. Then it starts failing again on a slower CI runner, so someone bumps it to sleep(5000). Now your test suite takes twenty minutes longer to run and it is still not fully reliable. ...

In the previous post, we sorted out static and dynamic test data. This time we tackle something that quietly bloats a lot of test suites. Setup code. If you have written more than a handful of Playwright tests, you have probably written a beforeEach block that logs a user in, or sets up a page object, or seeds some starting state. Do that across twenty spec files and you end up with the same boilerplate copied everywhere, and a small change to the login flow means touching every single file. ...

In the previous post, we cleaned up how our tests interact with the UI using the Page Object Model. This time we look at a different kind of mess. Test data. Here is a scenario that plays out on almost every team at some point. Two tests both try to register a new account using the email test@example.com. Run them one at a time and everything is fine. Run them at the same time in a parallel CI job, and one of them fails because the account already exists. Nobody touched the test code. The problem is the data. ...

In the previous post, we scaffolded a Playwright project and set up a folder structure with an empty pages/ directory sitting there waiting to be used. Today we fill it in properly. Here is a problem I see all the time. A test file has ten tests in it. Every single one of them repeats the same selector for the login button. Then the front end team renames a CSS class, and suddenly all ten tests break at once. You end up doing a find and replace across a dozen files just to fix one small UI change. ...

Every solid test automation framework starts the same way. You pick a clean folder structure. You get your config right once, early, before you have hundreds of tests depending on it. Playwright makes this part refreshingly easy. TypeScript support is built in from day one. You do not need to bolt on extra plugins or wrestle with a transpiler. This post walks through setting up a Playwright project the way I would actually set one up for a real team. Not a toy demo. Something that can grow to hundreds of tests without turning into a mess. ...

Lately, it feels like we’ve hit a real tipping point with web automation. Selenium had a great decade-plus run, but for me, Microsoft Playwright has officially taken over as the go-to tool for modern web testing. It’s just so much faster and smoother to work with. At the same time, I’ve been keeping an eye on the flood of new commercial “low-code” AI test tools popping up everywhere, trying to see if they actually deliver on bridging the gap between manual testing and automated pipelines. ...

The initial novelty of pasting prompts into web browser windows has pretty much worn off. Lately, I’ve been way more interested in how AI fits directly into the everyday coding workflow—mostly tinkering with GitHub Copilot and inline code completions right inside the editor. At the same time, my own approach to test automation has been shifting. I’ve been leaning much harder into API and microservice testing lately, mostly because keeping heavy UI tests reliable as apps change fast is a constant uphill battle. ...