Cover More Ground Without More Test Code: What’s New in Applitools Eyes and Autonomous

As your app grows, so does the gap between what you can test and what you have time to write: more screens, more edge cases, more documents to check. Applitools shipped four capabilities that close that gap without more test code: plain-English diff descriptions in Eyes, and Dynamic Match Level, conditional steps, and PDF testing in Autonomous.

Cut triage time with plain-English diff descriptions

Eyes now classifies every visual difference between a baseline and a checkpoint into a sentence, not just a highlighted pixel region. Instead of opening dozens of failed checkpoints one at a time to figure out what changed, you get a description like “Font family was changed from Calibri to Arial” attached to each diff.

Diff descriptions fall into three categories: formatting and style (font, color, weight, background, border), content and data integrity (text and graphic changes, with before/after values for short text changes), and unclassified differences for anything that doesn’t fit the first two.

That classification is what makes the feature useful at scale. The Batch Overview on the Test Results page rolls up every diff description in a batch and lets you regroup the whole view by diff description with one click, so a font swap that touched 30 checkpoints reads as one explanation instead of 30 separate investigations. The same descriptions surface in the Step Editor, the server API, and the Applitools MCP server for AI-assisted review.

Branch one test instead of writing three

Autonomous custom flow tests can now branch based on what’s on the screen, using plain-English conditional steps. Before this, testing two paths through one flow, a returning user versus a guest, a promo banner that may or may not appear, meant writing separate tests or chaining Optionally steps that skip silently with no visibility into which path ran.

Conditional steps use plain-English keywords to introduce a condition: given that, providing that, if, only if, if and only if, and unless. A condition block supports one if, any number of else if branches, and an optional else branch:

if "do you want to leave a tip?" is visible on the page
  - type "15%" next to "tip"
  - click "pay now"
else
  - type "10%" next to "tip"
  - click "pay now"

Anything you can already write as an assertion (visibility, text, element state, URL, variable comparisons) works as a condition, combinable with and, or, and not. When a condition is false, the block is skipped, its steps get a “Skipped” status, and the test keeps running: a false condition never fails the test.

Conditional steps and Optionally solve different problems, and a single step can’t use both. Optionally attempts a one-off action without blocking the test if it fails; a conditional step tests a branch explicitly, with a visible record of which path ran.

Stop flagging content that’s supposed to change

Autonomous now defaults every new test to Dynamic Match Level, replacing a strict, pixel-for-pixel comparison that flagged dates, prices, order numbers, and generated IDs as diffs on every run, even when nothing was broken, and that turned one changing value into a cascade of false positives whenever it shifted the elements around it.

It still runs a full Strict comparison, but recognizes content that changes by design using six built-in patterns (dates, emails, links, numbers, currency, input fields) or custom .NET regex patterns you define, for example a FinServ account-number format that isn’t one of the six defaults. It also absorbs the positional shift that changing content causes in neighboring elements, so a longer order number or wider price doesn’t surface a second diff for the label next to it.

It applies automatically to new tests with no setup required. Existing tests keep their current match level until you update them manually.

🎥 See all that’s new in Applitools in action

Validate a PDF the same way you validate a page

Applications generate PDFs constantly: invoices, contracts, statements, compliance reports. Validating one used to mean stepping outside your test tool: downloading the file, extracting its text with a separate library, running a separate image-comparison tool, and stitching the results together in a script that was fragile and slow to maintain as the document changed.

Autonomous custom flow tests can now open a PDF and test it directly within a Custom Flow Test, with the same Visual AI, text assertions, and interactions you’d use on a web page, with no separate pipeline required.

You open a PDF as the test’s start URL, or by navigating to one mid-flow with a Go to step or a click on a link that resolves to a PDF. Once open, Autonomous renders it in the interactive browser and supports:

• Text assertions on specific pages, for example: Verify that the first page contains “Total Amount”.
• Page navigation by ordinal or number: Go to the second PDF page, Jump to the 5th page.
• Visual checkpoints on the current page with “Visually check this screen”.
• Form interaction for fillable PDFs, using the same commands as web forms.

PDFs render in one dedicated environment rather than across a browser and device matrix, so a passing result reflects the document’s content, not how one browser’s PDF viewer displays it. One limit worth knowing up front: scanned PDFs aren’t supported, since there’s no underlying text or structure to assert against.

What’s coming next

Three more changes are already in motion for Eyes and Autonomous. PDF testing is due for a second phase that validates a full batch of documents at once, closer to how a full website test works today. Two other threads are in motion alongside that: an MCP Server that reaches Selenium, Cypress, and Appium instead of just Eyes and Playwright, and accessibility testing built directly into Autonomous, running axe-core WCAG 2 AA/AAA checks and Eyes’ contrast advisor on every custom flow step.

FAQs