DEV.co
Open-Source Testing · takahirom

roborazzi

Roborazzi is a Kotlin-based screenshot testing library that runs Android integration tests on the JVM using Robolectric, enabling visual regression testing without device emulators. It integrates with Robolectric's Native Graphics mode to capture and compare UI screenshots, helping teams detect visual bugs early in the development cycle.

Source: GitHub — github.com/takahirom/roborazzi
974
GitHub stars
54
Forks
Kotlin
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorytakahirom/roborazzi
Ownertakahirom
Primary languageKotlin
LicenseApache-2.0 — OSI-approved
Stars974
Forks54
Open issues127
Latest release1.66.0 (2026-07-06)
Last updated2026-07-07
Sourcehttps://github.com/takahirom/roborazzi

What roborazzi is

Roborazzi provides a Gradle plugin and testing library that instruments JVM-based Android tests with screenshot capture/comparison capabilities. It leverages Robolectric 4.10+ with @GraphicsMode(NATIVE) to render Android UI server-side, generate baseline images, and perform pixel-level diff comparisons via Gradle tasks (record, verify, compare).

Quickstart

Get the roborazzi source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/takahirom/roborazzi.gitcd roborazzi# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Continuous Visual Regression Testing

Detect unintended UI changes in pull requests by running screenshot comparisons in CI/CD pipelines without device farms, reducing false negatives and flaky test failures.

Jetpack Compose Component Testing

Validate Compose UI behavior and appearance with Robolectric and Hilt support, enabling fast local testing of composable functions with real dependency injection.

Early-Stage Feature Development & Design Review

Capture and review UI changes during development before emulator/device testing, accelerating feedback loops for design and product teams.

Implementation considerations

  • Requires Robolectric 4.10+ and @GraphicsMode(NATIVE) annotation on test classes; adding Roborazzi plugin and test dependencies to build.gradle.kts is straightforward but depends on existing Robolectric setup.
  • Default output directory is build/outputs/roborazzi; baseline images should be committed to version control and diff images reviewed in pull requests to manage visual test expectations.
  • Multiple Roborazzi tasks can race on shared directories in concurrent Gradle builds; experimental per-variant output directory option available but requires explicit configuration.
  • Gradle tasks (recordRoborazziDebug, compareRoborazziDebug, verifyRoborazziDebug) must be run explicitly or via test properties; integration with standard testDebugUnitTest task requires gradle.properties or CLI flags.
  • Screenshot baselines grow over time; clear image caching and output directories with caution using clearRoborazziDebug to avoid losing test history.

When to avoid it — and what to weigh

  • No Android Development Workflow — If your project is not Android-based or does not use Gradle, Roborazzi offers no value. It is tightly coupled to JVM-based Android testing.
  • Device-Specific Hardware Testing Required — If your app requires testing on real devices (e.g., camera, GPS, sensors, OS-specific behavior), JVM screenshot tests cannot replicate those interactions.
  • Small Team Without CI/CD Setup — If you lack a CI/CD pipeline or screenshot baseline storage infrastructure, manual image review and diff management becomes burdensome.
  • Runtime Behavior Not Visual — If your testing needs focus on logic, concurrency, or non-visual runtime behavior, screenshot testing is not the primary solution.

License & commercial use

Licensed under Apache License 2.0, a permissive OSI-approved open-source license allowing commercial use, modification, and distribution with proper attribution.

Apache 2.0 permits unrestricted commercial use, including in proprietary products, provided the license and copyright notice are included. No commercial support entity or SLA is evident from the data; support relies on GitHub issues and community contributions.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityModerate
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No security-specific issues noted in provided data. Roborazzi runs as a Gradle plugin in the build environment and processes image files locally. No network calls, credential storage, or sensitive data handling evident. Standard Gradle/JVM supply-chain hygiene applies (dependency pinning, plugin integrity). Baseline image storage should follow standard version control security practices.

Alternatives to consider

Paparazzi

Similar screenshot testing library, but incompatible with Robolectric; does not support Hilt or Android framework mocking. Roborazzi bridges this gap for JVM-based instrumentation tests.

Espresso + Android Emulator

Traditional device/emulator-based UI testing. More realistic but slower, flakier, requires emulator infrastructure; Roborazzi trades device fidelity for speed and determinism.

Manual Visual Testing + Manual Regression

No automation. Time-consuming, error-prone; Roborazzi automates visual regression detection but requires baseline management and CI/CD integration.

Software development agency

Build on roborazzi with DEV.co software developers

Evaluate Roborazzi's Gradle plugin and screenshot comparison workflow with a proof-of-concept on a single feature module. Ensure Robolectric 4.10+ is installed and plan baseline image storage in CI/CD before full adoption.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

roborazzi FAQ

Does Roborazzi replace device/emulator testing?
No. Roborazzi runs JVM tests and cannot test hardware interactions (camera, GPS, sensors, real OS behavior). Use it alongside emulator/device tests for UI regression; device tests remain necessary for end-to-end validation.
How are baseline images stored and reviewed?
Baseline images are saved to build/outputs/roborazzi (customizable) and should be committed to version control. Comparison images are generated on verify/compare, and diffs are shown in HTML reports. Diff approval workflow is manual—teams must implement review gates in CI/CD.
What is the performance overhead compared to standard unit tests?
Unknown from provided data. JVM screenshot rendering is faster than emulator tests, but baseline/comparison image I/O and diff computation add overhead. Benchmarks not provided; testing in your project context is advised.
Is Roborazzi suitable for a team without Robolectric experience?
Requires existing Robolectric setup (4.10+) and @GraphicsMode(NATIVE) annotation; not a drop-in replacement. Teams new to Robolectric should first establish basic JVM test infrastructure before adopting Roborazzi.

Software development & web development with DEV.co

From first prototype to production, DEV.co delivers software development services around tools like roborazzi. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source testing and beyond.

Ready to Add Visual Regression Testing to Your Android Pipeline?

Evaluate Roborazzi's Gradle plugin and screenshot comparison workflow with a proof-of-concept on a single feature module. Ensure Robolectric 4.10+ is installed and plan baseline image storage in CI/CD before full adoption.