# visual-regression-testing Published articles for visual-regression-testing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Introducing Visual Testing in Maestro DevFeed: [Introducing Visual Testing in Maestro]() Original publisher: [Read original article]() Author: Dan Caseley Published: 2026-03-02T07:00:00Z Content type: release Language: en Sources: [mobile.dev - Medium]() Topics: [Testing](), [Command-line interface]() Tags: [cli](), [maestro](), [regression](), [screenshot](), [screenshot-testing](), [screenshots](), [testing](), [visual-regression-testing](), [visual-testing]() ### AI overview Maestro's Visual Testing compares screenshots with saved baselines to detect unexpected visual changes. The article explains assertScreenshot, takeScreenshot, cropOn, and thresholdPercentage, and describes use cases including shared design-system components, dependency upgrades, dark mode, and complex layouts. ### Source excerpt Available in CLI v2.2.0, Maestro Studio, and Maestro Cloud ## Improving Frontend Regression Testing with Chromatic DevFeed: [Improving Frontend Regression Testing with Chromatic]() Original publisher: [Read original article]() Author: Stephen De Vaux Published: 2026-01-30T01:00:49Z Content type: article Language: en Sources: [Kogan.com]() Topics: [Front end](), [Testing](), [Storybook](), [Remix](), [browser](), [ci](), [Automation](), [pull-requests](), [Developer experience](), [unit test]() Tags: [automation](), [browser](), [ci](), [developer-experience](), [frontend](), [pull-requests](), [regression](), [remix](), [storybook](), [testing](), [ui](), [unit-test](), [visual-regression-testing]() ### AI overview The article explains how Kogan integrated Chromatic into a Remix-based frontend testing workflow to detect visual regressions that traditional unit tests may miss. It describes Chromatic's Storybook integration, browser screenshots, baseline comparisons, CI workflow, and the differences between UI Review and Visual Tests. ### Source excerpt After recently migrating our frontend to Remix, we took the opportunity to reassess how we approach frontend testing, particularly regression testing. While we already had unit test coverage, we identified a gap when it came to validating UI changes. This is where Chromatic became a part of our frontend testing strategy. This post outlines why we introduced Chromatic and how it fits into a Remix-based workflow. Even when application functionality remains unchanged, subtle visual regressions can still be introduced. Changes to spacing, typography, layout, or component states can easily slip through without being caught by traditional tests. What we needed was a way to automatically detect meaningful UI changes while still fitting into our existing development workflow. At the same time, it was important to avoid introducing a fragile or high-maintenance testing setup, one that adds overhead without delivering proportional benefit. Our implementation with Chromatic attempts to balance automation, reliability, and developer experience as a practical addition rather than an extra burden. Why Chromatic? Chromatic provides visual regression testing on top of Storybook. Instead of testing components purely through assertions, Chromatic renders components in a real browser environment and captures screenshots. These are then compared against a known baseline to highlight visual changes. The key reasons we chose Chromatic were: Automated visual diffs that are easy to review Integration with Storybook, which we already use for component development CI-friendly workflow that fits well into pull requests Chromatic offers two closely related features for reviewing UI changes: UI Review and Visual Tests. While they have some overlap of functionality, they serve different purposes and are designed for different levels of enforcement. UI Review is enabled by default, whereas Visual Tests are an optional feature. UI Review generates snapshots that highlight differences against a bas ## Upgrading frontend dependencies with confidence DevFeed: [Upgrading frontend dependencies with confidence]() Original publisher: [Read original article]() Author: Sébastien Lorber Published: 2023-09-22T00:00:00Z Content type: article Language: en Sources: [Docusaurus Blog]() Topics: [visual-regression-testing](), [Front end](), [GitHub Actions](), [Playwright](), [Testing](), [upgrade](), [GitHub]() Tags: [frontend](), [github](), [github-actions](), [npm](), [playwright](), [regression](), [release](), [testing](), [upgrade](), [visual-regression-testing]() ### AI overview This article presents a visual regression testing workflow for upgrading frontend dependencies with greater confidence. It combines GitHub Actions, Playwright, and Argos to build sites, capture screenshots across Git branches, compare them, and report visual differences through commit statuses and pull-request comments. ### Source excerpt Upgrade npm dependencies with confidence thanks to a visual regression testing workflow using GitHub Actions, Playwright and Argos. ## Understanding & Assessing Visual Regression Testing DevFeed: [Understanding & Assessing Visual Regression Testing]() Original publisher: [Read original article]() Author: Nikhita Reddy Eega Published: 2023-07-27T12:58:43Z Content type: tutorial Language: en Sources: [Android@Microsoft - Medium]() Topics: [Testing](), [Jetpack Compose](), [Kotlin](), [Declarative programming](), [ui](), [XML]() Tags: [capture](), [cashapp-paparazzi](), [declarative](), [facebook-sdk](), [jetpack-compose](), [kotlin](), [mobile](), [snapshots](), [testing](), [verify](), [visual-regression-testing]() ### AI overview This article explains visual regression testing for Android UI, focusing on possible visual differences when migrating from the View system to Jetpack Compose. It describes recording baseline snapshots, verifying new snapshots against them, and evaluating VRT tools such as Facebook SDK and Paparazzi for framework compatibility. ### Source excerpt Understanding & Evaluating Visual Regression TestingPhoto by Jessica Ruscello on UnsplashDive into learning about VRT tools like Facebook SDK, Paparazzi and study their compatibility for migration. Since Jetpack Compose was released in 2021, its declarative programming model has offered a modern and intuitive approach to building user interface. Compared to View system framework, Compose promotes cohesion and simplifies state-management. This framework is lightweight because the UI components are built using composable functions as separate building pieces. With this paradigm shift, boilerplate code is lessened, code reuse is encouraged, and the development process is made simpler. Migrating to Compose seems quite appealing. Will there be any regression if we migrate from one framework to another, though? Because Compose is still relatively new compared to the well-established View-based UI, there might be potential challenges faced during the migration period. What about visual regressions? Possible visual regressions can be encountered due to different UI frameworks, view configuration and styling approach. Styling and themes are usually defined in XML resource files which are applied to the views and then rendered. Whereas in Compose, these are programmatically defined in Kotlin and then takes advantage of efficient recomposition. These variances may result in changes to padding, margin, etc. Thus, to maintain a seamless transition and avoid any visual bugs going unreported, visual regression testing can be used. This ensures that the final UI is consistent to enhance user experience. Understanding Visual Regression Testing (VRT): Let us now break down the process into two design approaches -- High level and Low level High-Level Design Approach Consists of 2 steps: 1) Record -- Generating a snapshot and saving it as Golden (baseline/reference snapshot used to compare subsequent snapshots) 2) Verify -- Compares the two snapshots High level design flowLow-Level Design ## Screenshot testing with React and Storybook DevFeed: [Screenshot testing with React and Storybook]() Original publisher: [Read original article]() Author: Jesse Pinho Published: 2018-03-19T09:18:02Z Content type: tutorial Language: en Sources: [Bleeding Edge - Medium]() Topics: [screenshot-testing](), [Storybook](), [React](), [Testing](), [styled-components](), [Selenium]() Tags: [continuous-integration](), [react](), [screenshot-testing](), [selenium](), [storybook](), [styled-components](), [testing](), [visual-regression-testing]() ### AI overview The article explains why end-to-end UI tests can miss visual regressions and explores screenshot testing with React and Storybook to check component appearance across different states. ### Source excerpt Visual regression testing for fun, profit, and peace of mind Illustration by Marta Pucci A friend of mine recently related a scary story about the lack of automated visual regression testing where he works--a huge international tech firm that you've heard of and probably use. He'd added a CSS class to an element to hide it from the user. Unbeknownst to him, and despite using BEM-style naming for CSS classes, this class name was already being used for an important checkbox in the user settings screen of his company's web app. The result? Users could no longer change the setting represented by the checkbox, because it was invisible! I asked him why that hadn't been caught by automated tests. He explained that, although they did have end-to-end tests in place that went through the UI and tested its functionality, the tests didn't catch the bug. Selenium was still able to check the original checkbox via its selector, so its visibility had no effect on the outcome of the test. The only way this could have been caught is via visual regression testing -- or, as it is sometimes called, screenshot testing. 💅 Switching to styled-components I recalled this story recently while working on a sizable project at Clue: converting all of our "native" CSS to use styled-components. The new helloclue.com website consists of dozens of components. An article page, for example, contains at least ten different React components, all of which have accompanying CSS files. Converting all of this CSS to styled-components means there's an enormous risk of bugs exactly like the one my friend experienced. So before the project began, I investigated setting up screenshot testing for the site. 📕 Enter Storybook (Note: if you're already familiar with Storybook and @storybook/react, feel free to skip to the next section.) We use Storybook when developing simple presentational components. This way, we can test them in every possible state, without having to reproduce all the logic and so forth required t