Mobile Testing
Espresso is Google's official Android UI testing framework. It's built into the Android Testing Support Library, runs directly on the device or emulator, and provides a concise API for interacting with and asserting on your app's UI. Unlike Appium or UiAutomator that use external
Testing
Appium is the standard for mobile test automation. Repeato is a newer, no-code alternative. They solve the same problem — automating iOS and Android app testing — but with fundamentally different approaches that make them appropriate for very different teams and situations. The Core Difference Appium is a WebDriver-based framework.
Testing
Repeato records tests on both iOS and Android, but the setup path differs between platforms. iOS requires Xcode and either a simulator or provisioned real device. Android needs ADB and either an emulator or USB-connected device with debugging enabled. This guide covers both paths in detail, plus practical tips
Testing
Repeato is a no-code mobile testing tool that uses computer vision to record and replay test interactions on iOS and Android apps. Instead of writing Appium scripts or XPath selectors, you record your actions once and Repeato uses visual recognition to replay them — even when UI elements shift position
Testing
Traditional mobile test automation — Appium, XCUITest, Espresso — works by querying the app's accessibility tree. Every interaction targets an element by ID, XPath, or accessibility label. This works well until the app changes: rename a resource ID, restructure a layout, and tests start throwing NoSuchElementException. Repeato takes a different
Testing
Recording tests in Repeato's desktop app is one thing — getting them running automatically on every commit is another. Repeato provides a CLI tool that runs tests headlessly, which means you can wire it into GitHub Actions, Jenkins, GitLab CI, or any other pipeline that can run shell commands.
Mobile Testing
Mobile teams constantly fight the same battle: test code for iOS and Android is 80% identical but diverges on selectors, gestures, permission dialogs, and platform-specific behaviors. The naive approach is two separate test suites. The right approach is shared test logic with platform adapters. This guide covers the architectural
Testing
Calabash and Appium solve the same problem — automated UI testing of mobile apps — but with fundamentally different architectures, different language support, and very different maintenance trajectories. The short version: Calabash is deprecated and archived. Appium is actively maintained. If you are choosing a framework today, choose Appium. If you maintain
Testing
Calabash iOS works by embedding a small HTTP server (calabash.framework) into a special test build of your app. When the app launches, it listens on port 37265. Your Ruby test code sends HTTP requests to this server to query the view hierarchy and send touch events. The production build
Testing
Calabash uses Cucumber as its test runner, which means your tests are written in Gherkin — the same plain-language format used by web-focused BDD tools like Capybara. A Gherkin scenario describes behavior in terms a non-engineer can read. The Ruby step definitions underneath translate those sentences into Calabash
Testing
Calabash is a cross-platform mobile UI testing framework built on top of Cucumber. It lets you write tests in Gherkin (Given/When/Then) and execute them against real iOS and Android apps. The framework works by embedding a small HTTP server into your app at test time, giving your
Testing
Calabash Android tests run against a specially instrumented version of your APK. The instrumentation wraps your app with a small HTTP server (powered by Robotium) that Calabash's Ruby client talks to over a local socket. This means you never modify your production binary — the test build is a