DEV Community: Aegis Runner

AegisRunner vs Playwright — Get Playwright Tests Without Writing Them

Aegis Runner — Thu, 26 Mar 2026 12:16:33 +0000

Playwright is arguably the best browser automation framework available today. Cross-browser support, auto-waiting, network interception, and excellent TypeScript support make it the tool of choice for modern test automation.

But Playwright is a framework, not a solution. It gives you the building blocks — you still need to architect, write, and maintain your tests.

AegisRunner uses Playwright under the hood. Same engine, same reliability, same cross-browser support. The difference: you never write a line of Playwright code. The AI does it for you.

Playwright: The Power and the Cost

npm init playwright@latest

Simple to install. Then the work begins:

Design your test structure — page objects, fixtures, helpers
Write test files — one per feature area
Add assertions — what to check on each page
Handle authentication — login flows, session management
Configure CI — GitHub Actions, parallel workers, sharding
Maintain tests — fix broken selectors, update assertions, add new tests

For a 50-page application, expect 80-160 hours of initial test writing, plus ongoing maintenance.

AegisRunner: Playwright Without the Code

AegisRunner runs the same Playwright browser engine. When you start a crawl, it:

Launches Playwright Chromium (or Firefox, or WebKit)
Navigates to your URL
Discovers every page via links and sitemap
Interacts with every element — clicks, fills, toggles, hovers
Captures screenshots and DOM snapshots
Generates Playwright-compatible test cases

The generated tests use real CSS selectors, text matchers, and role-based locators — the same best practices Playwright recommends.

What You Get vs What You Build

Capability	Playwright (DIY)	AegisRunner
Test creation time	1-2 hours per page	Minutes (automatic)
Selector strategy	You choose	Auto-selected (CSS, text, role)
Cross-browser	Configure yourself	Built-in
Visual regression	Plugin required	Built-in
Accessibility	@axe-core/playwright plugin	Built-in
Test maintenance	Manual	Auto-healing
CI/CD setup	Write YAML yourself	One-click webhook
Parallel execution	Configure sharding	Built-in
Page discovery	You list the pages	Automatic crawl + sitemap

The Best of Both Worlds

AegisRunner doesn't replace Playwright — it uses it. If you're a Playwright power user, you can:

Let AegisRunner generate the initial test suite
Export tests as .spec.ts files
Customize and extend them in your own codebase
Use AegisRunner for regression monitoring alongside your custom tests

This gives you the speed of AI generation with the flexibility of hand-written tests when you need them.

Who Should Use Raw Playwright

Stick with raw Playwright if:

You enjoy writing tests and have the time
You need extremely custom test logic (complex state machines, mock servers)
You're building a testing framework for others to use
You want to learn browser automation deeply

Who Should Use AegisRunner

Use AegisRunner if:

You want Playwright-quality tests without writing code
You need comprehensive coverage quickly
Your team lacks dedicated test engineers
You want accessibility, SEO, and security bundled with regression tests

Get Started

Your existing Playwright knowledge isn't wasted. AegisRunner generates the same kind of tests you'd write — just faster.

Try it free — paste your URL and see the Playwright tests it generates.

AegisRunner vs Meticulous.ai — Two Opposite Approaches to Killing Manual Tests

Aegis Runner — Mon, 23 Mar 2026 16:57:18 +0000

The testing industry is converging on a shared belief: manually writing tests doesn't scale. Two companies are attacking this problem from opposite directions.

Meticulous.ai records real user interactions from production traffic and replays them as tests. Their pitch: "tests are dead" — replaced by production recordings.

AegisRunner crawls your application with an AI-driven browser and generates tests from the discovered page structure. The pitch: paste a URL, get a complete test suite.

Both eliminate manual test writing. But the approaches have fundamentally different trade-offs.

How Meticulous Works

Meticulous installs a JavaScript snippet on your production site. This snippet records every user session — clicks, scrolls, form fills, navigation. The recorded sessions are then replayed as tests against new deployments.

The advantage: tests reflect real user behavior, not hypothetical scenarios.

The trade-offs:

Requires production traffic. New features with no production usage have no tests.
Privacy concerns. Recording production sessions raises GDPR and privacy questions.
Production dependency. Your testing pipeline depends on your production environment.
No pre-production testing. You can't test staging or dev environments without real traffic.

How AegisRunner Works

AegisRunner visits your application with an automated browser, discovers every page and interactive element, and generates tests based on the page structure.

The advantage: works on any environment — production, staging, development, localhost. No real user traffic needed.

The trade-offs:

Synthetic interactions. The crawler explores every possible interaction, not just the ones real users take.
Discovery-based. Tests are based on what's on the page, not user intent.

Feature Comparison

Feature	Meticulous.ai	AegisRunner
Test source	Production traffic recordings	AI-driven crawl and discovery
Works on staging/dev	Limited	Yes — any URL
Requires production snippet	Yes	No
Privacy concerns	Yes (recording user sessions)	No (synthetic crawl)
New feature coverage	Only after users interact	Immediate (crawl discovers it)
Visual regression	Yes	Yes
Accessibility testing	No	Yes (WCAG 2.1, axe-core)
SEO auditing	No	Yes
Security scanning	No	Yes
Performance monitoring	No	Yes
Free tier	No	Yes
Setup time	Install snippet + wait for traffic	Paste URL + start crawl

The "Tests Are Dead" Debate

Meticulous's marketing claims tests are dead — that recording and replaying production behavior makes traditional tests obsolete.

There's a compelling argument there. Production recordings capture real user workflows that test engineers might never think to write.

But there's a counter-argument: production recordings only cover what users have already done. They don't test edge cases, error states, or new features that haven't been used yet.

AegisRunner's approach covers both. The crawler explores every discoverable path — including error states, empty states, and edge cases that real users haven't triggered yet. It finds the broken "Add to Cart" button before any customer encounters it.

When to Choose Meticulous

You have significant production traffic
Your primary concern is ensuring existing workflows don't break
You're comfortable with a production JavaScript snippet recording sessions
Privacy regulations aren't a concern

When to Choose AegisRunner

You need to test staging or development environments
You want testing before you have production traffic
Privacy regulations prevent recording user sessions
You need accessibility, SEO, and security testing alongside regression tests
You want a free tier to evaluate before committing

Can You Use Both?

Yes. Meticulous covers real user workflows from production. AegisRunner covers synthetic exploration of every possible interaction. Together, they provide the most comprehensive coverage.

But if you have to choose one: do you have enough production traffic to make Meticulous effective? If not, AegisRunner gives you full coverage from day one.

Try it free — paste your URL and see what AegisRunner discovers. No signup, no snippet installation.

Why Your UI Tests Break Every Sprint (And How to Fix It for Good)

Aegis Runner — Wed, 18 Mar 2026 06:55:15 +0000

You push a design update. The button still works. The user flow is unchanged. But your CI is red.

Sound familiar?

This is the daily reality for teams whose test suites are built on CSS selectors. Someone renames .btn-primary to .btn-primary-v2, restructures a form, or swaps a<div>for a <section> — and suddenly 60 tests fail. Not because anything is broken. Because the tests were looking for the wrong thing.

The Root Cause: Tests That Know Too Much

When you write a selector like this:
document.querySelector('#checkout > div:nth-child(3) > input.form-control')
you're not describing what the user experiences. You're describing how a developer happened to structure the DOM on a particular Tuesday.

That's a snapshot, not a contract.

The Fix: Test What the User Sees

Modern testing best practice flips the model: target elements by ARIA role and visible text, not by class names or DOM position.
// Fragile ❌
cy.get('.btn-primary-v2').click()

// Resilient ✅
cy.findByRole('button', { name: 'Submit Order' }).click()

The second selector survives any redesign. As long as the button still says "Submit Order" and has role="button", it will be found — regardless of what happened to the surrounding markup.

This approach, sometimes called selector resilience, is the difference between a test suite that helps you ship faster and one that slows you down.

The Hidden Benefit: Accessibility Auditing Built In

Here's the part most teams don't realise: if your test can't find an element by role or label, that's a real bug — not just a test failure.

A button without an accessible name is invisible to screen readers and to your test runner. Your test suite becomes a live accessibility audit, catching issues before they reach users.

Applying This at Scale

Manually refactoring hundreds of selectors is painful. The better approach is to generate tests that are resilient from the start — crawling your app and writing selectors against roles and labels automatically.

That's exactly what AegisRunner does. It crawls your application, discovers interactive states, and generates Playwright tests that use ARIA roles and visible text — so they don't break when your designers do their job.

If you're evaluating tools, this 2026 roundup of regression testing software is worth a read — it covers how different tools handle selector stability.

Quick Checklist

Before your next sprint, audit your selectors:

Replace index-based queries (nth-child) with role queries
Replace class-based selectors with label/text queries
Any element your test can't find by role → file an accessibility ticket
Add a linting rule to ban .querySelector in test files

Stop writing tests that know your implementation. Write tests that know your product.

If you want a tool that handles this automatically, AegisRunner's pricing starts free — no credit card required.

Have a selector horror story? Drop it in the comments.