Top 12 Open Source Alternatives to Airtest + Poco
Introduction and Context
Airtest + Poco originated from the needs of mobile game and app testing, where traditional DOM- or accessibility-based selectors were not enough. Built and open-sourced by NetEase, the stack combines two complementary pieces:
Airtest: a cross-platform UI automation framework that relies heavily on computer vision (CV). It can locate and interact with on-screen elements by image matching and templating, which is especially useful for games and custom-rendered interfaces.
Poco: a UI hierarchy driver that exposes the in-app object tree for common game engines and native apps, so tests can target UI elements more semantically when available.
This combination gained popularity for several reasons:
It uses Python, a familiar language for test engineers and data practitioners.
It spans Android, iOS, and Windows, covering mobile, desktop, and game interfaces.
It ships with Airtest IDE to record, visualize, and replay tests, reducing the initial barrier to entry.
It integrates with CI/CD pipelines and supports modern workflows such as containerized runners and artifact collection.
Despite its strengths, teams often explore alternatives to better fit their tech stacks, simplify maintenance, or gain more stable locators than pure image-based automation. As mobile frameworks, desktop app stacks, and web technologies evolve, specialized tools may offer a smoother experience for specific platforms or test styles. Below, we review twelve open source options that teams consider alongside or instead of Airtest + Poco.
Overview: Top 12 Open Source Alternatives
Here are the top 12 alternatives to Airtest + Poco covered in this guide:
Airtest Project
Appium Flutter Driver
Capybara
FitNesse
Maestro
Playwright Component Testing
Protractor (deprecated)
Selene (Yashaka)
Serenity BDD
UI Automator
White
Winium
Why Look for Airtest + Poco Alternatives?
Locator stability in complex UIs: CV-based testing can be brittle if images change due to animations, scaling, themes, or localization. Even with good baselines and thresholds, visual diffs can introduce flakiness if tests are not carefully structured.
Setup and maintenance overhead: Managing devices, simulators, IDE tooling, and image assets adds maintenance. Teams may prefer a simpler declarative approach, a framework native to their language, or a driver that matches their app’s UI tree out of the box.
Platform or framework specialization: Flutter, React Native, Windows desktop (Win32/WPF/UWP), and pure web components often benefit from tools optimized for those environments rather than general CV automation.
Team skill set and language preference: Some teams are anchored in Ruby, JavaScript/TypeScript, Java/Kotlin, or .NET, and prefer a tool that aligns with their existing testing conventions and libraries.
Reporting, patterns, and test architectures: Certain frameworks emphasize test readability, reusable patterns (e.g., the Screenplay pattern), and reporting that makes failures easier to diagnose and communicate.
Detailed Breakdown of Alternatives
1) Airtest Project
What it is: Airtest Project is an open source game UI automation toolkit focused on Android and Windows. Like Airtest, it uses CV-based interactions and scripting in Python, making it attractive to teams testing 2D/3D games and custom-rendered screens.
Core strengths:
Optimized for games and custom UI where DOM or accessibility trees are limited.
Python-based workflow that aligns with data and automation teams.
Works well with image templates, coordinates, and device-level commands.
Supports continuous integration environments and artifact capture.
Flexible enough to combine with other tools for hybrid strategies.
How it compares to Airtest + Poco:
It overlaps significantly with Airtest’s CV approach. If you rely heavily on CV and you do not need Poco’s object-tree capabilities, Airtest Project alone can be a leaner path.
Teams that need finer control over CV assets or operate primarily on Android/Windows game UIs may find it sufficient.
If you need a richer object model for elements (e.g., game engine hierarchies), Airtest + Poco remains stronger.
2) Appium Flutter Driver
What it is: Appium Flutter Driver extends Appium to target Flutter apps on Android and iOS. It exposes Flutter widgets for testing via element locators that understand Flutter’s tree, reducing reliance on image matching.
Core strengths:
Flutter-specific element access for stable locators and interactions.
Works across Android and iOS with a unified approach to Flutter widgets.
Aligns with Appium’s ecosystem, clients, and CI integrations.
Supports standard test patterns and structured reporting through Appium clients.
Reduces CV dependency by using Flutter’s introspection APIs.
How it compares to Airtest + Poco:
For Flutter apps, Appium Flutter Driver offers more stable element selectors than CV, improving test reliability and maintainability.
Airtest + Poco is more general-purpose and can handle CV-heavy or hybrid scenarios, but for Flutter-first teams, Appium Flutter Driver is often simpler and more robust.
If your app mixes Flutter with non-Flutter views, you may still combine approaches or fall back to Appium’s general drivers.
3) Capybara
What it is: Capybara is a Ruby library for end-to-end web UI testing. Often paired with RSpec or Cucumber, it provides expressive, readable DSLs to model user behavior and assert on web elements.
Core strengths:
High-level, readable DSL that matches how users interact with web pages.
Works with multiple drivers (e.g., Selenium, headless browsers) and integrates with Ruby test ecosystems.
Encourages clean test design and robust synchronization through smart waiting.
Strong community patterns and plugin ecosystem for reporting and fixtures.
How it compares to Airtest + Poco:
Capybara is web-focused and ideal for teams building primarily for browsers. If your target is a web app, it offers more stable element locators and established best practices than CV-based testing.
Airtest + Poco can drive desktops and mobiles, but it is not specialized for modern web frameworks in the way Capybara is. For web-only projects, Capybara typically means less flakiness and more maintainable selectors.
Choose Capybara if your team is comfortable with Ruby and you want succinct, behavior-driven web UI tests.
4) FitNesse
What it is: FitNesse is a wiki-based acceptance testing and ATDD framework. It allows non-developers and developers to collaborate on executable specifications by writing examples in wiki pages, backed by fixtures.
Core strengths:
Readable, living documentation that bridges QA, dev, and business stakeholders.
Supports both web and API testing through custom fixtures.
Enables collaborative workflows where specifications and tests converge.
Encourages domain-focused test design and traceability.
How it compares to Airtest + Poco:
FitNesse is about acceptance criteria, collaboration, and specification-by-example rather than raw UI automation. It adds an abstraction layer that can wrap any automation mechanism below, including UI or API.
If your goal is shared understanding and ATDD across teams, FitNesse might fit better than a pure UI automation toolkit.
Airtest + Poco remains stronger for device control and image-based automation; FitNesse is stronger for shared, human-readable acceptance criteria.
5) Maestro
What it is: Maestro is an open source, declarative mobile UI testing framework for Android and iOS. It uses simple YAML flows to describe tests, aiming for a low-friction setup and easy onboarding.
Core strengths:
Declarative test flows that reduce boilerplate and scripting overhead.
Quick setup and execution across iOS and Android.
Good ergonomics for common mobile actions, navigation, and assertions.
CI-friendly with straightforward command-line usage and artifacts.
Lower barrier to entry for teams without deep coding background.
How it compares to Airtest + Poco:
Maestro trades Python code and CV templates for readable YAML flows. This can reduce flakiness and improve onboarding speed for standard mobile UI tests.
Airtest + Poco can handle complex custom-rendered UIs via CV or Poco. Maestro shines for typical native mobile apps where accessibility IDs and text locators suffice.
If you need deep, game-like CV automation, Airtest + Poco is more capable. If you want simple, stable mobile workflows, Maestro is a strong alternative.
6) Playwright Component Testing
What it is: Playwright Component Testing brings Playwright’s reliability and cross-browser engine to component-first testing for modern web frameworks. It focuses on testing UI components in isolation with real browser rendering.
Core strengths:
Component-first approach, improving feedback loops and test focus.
Robust, cross-browser execution with solid auto-wait and isolation.
Integrates with TypeScript/JavaScript tooling for web teams.
Fast local development cycles and strong debugging experience.
Seamless escalation from component to full end-to-end scenarios.
How it compares to Airtest + Poco:
For web UIs, component testing yields more stable, precise tests than image-based automation. It also shortens feedback loops and narrows failure scope.
Airtest + Poco is better suited for non-DOM UIs and system-level flows beyond the browser. For web-centric teams, Playwright-based testing is often a cleaner fit.
Choose Playwright Component Testing if your main challenge is ensuring component correctness across browsers in a JS/TS ecosystem.
7) Protractor (deprecated)
What it is: Protractor was an end-to-end testing framework for Angular applications. It has been officially deprecated, and it is no longer recommended for new projects.
Core strengths:
Historically provided Angular-aware synchronization and locators.
Large legacy base and familiarity in older Angular projects.
Built on WebDriver concepts with broad CI compatibility in its time.
How it compares to Airtest + Poco:
As a deprecated tool, Protractor is not advisable for new work. If you maintain a legacy Angular app with existing Protractor tests, plan a migration to Playwright, WebdriverIO, Cypress, or similar.
Airtest + Poco targets different platforms and approaches, and it remains active. For modern web testing, favor supported tools over Protractor.
If your need is web testing, moving to an actively maintained web framework is preferable to either Protractor or CV-based UI testing.
8) Selene (Yashaka)
What it is: Selene is a Python library inspired by Selenide, providing a concise, fluent API on top of Selenium for web UI testing. It emphasizes clean, readable code and smart waiting to reduce flakiness.
Core strengths:
Python-first, with elegant APIs for web UI tests.
Built-in smart waiting and concise element actions.
Integrates well with PyTest and Python tooling.
Supports multiple browsers through Selenium drivers.
Easy to learn for teams already using Python.
How it compares to Airtest + Poco:
If your targets are web applications and your team prefers Python, Selene offers a more stable, semantic approach than CV-based automation.
Airtest + Poco supports mobile and desktop in addition to web-like surfaces, but it is not optimized for DOM-centric testing.
Choose Selene for Pythonic web testing; choose Airtest + Poco for cross-device or game-like UI automation that benefits from CV.
9) Serenity BDD
What it is: Serenity BDD is an end-to-end testing and reporting framework for the JVM and JavaScript ecosystems, often paired with the Screenplay pattern. It integrates with Selenium and other drivers to provide rich documentation and traceability.
Core strengths:
Comprehensive reporting with visual documentation of test outcomes.
Encourages maintainable design via the Screenplay pattern.
Integrates with Selenium/WebDriver, REST testing, and more.
Strong alignment with BDD practices and living documentation.
Scales well in larger teams that value governance and visibility.
How it compares to Airtest + Poco:
Serenity BDD is about test architecture and reporting excellence in web/API testing. It provides patterns and documentation layers that Airtest + Poco does not.
For web-centric teams on the JVM or Node.js, Serenity can improve maintainability and communication.
Airtest + Poco remains a better fit for CV-heavy or mobile/desktop system automation without a DOM, but it lacks Serenity’s built-in reporting depth.
10) UI Automator
What it is: UI Automator is Google’s open source UI testing framework for Android. It automates at the system and app level, enabling interactions that cross app boundaries and target system UI.
Core strengths:
Deep Android integration with access to system UI and multi-app flows.
Stable selectors based on accessibility and view hierarchies.
Works well for device settings, permissions, and OS-level prompts.
Java/Kotlin support aligns with many Android engineering teams.
Reliable execution and strong tooling support in the Android ecosystem.
How it compares to Airtest + Poco:
For Android-only testing with system-level coverage, UI Automator often provides more stable, maintainable selectors than CV approaches.
Airtest + Poco offers broader platform coverage and CV capabilities for custom rendering. UI Automator is stronger when your tests rely on Android’s accessibility tree and OS-level workflows.
Choose UI Automator for Android-heavy pipelines and tighter integration with Android Studio and JVM tooling.
11) White
What it is: White is an older but still used .NET UI automation library for Windows desktop applications (Win32, WPF, Silverlight). It builds upon Microsoft UI Automation (UIA) to interact with desktop controls.
Core strengths:
Targets native Windows UI frameworks with a familiar .NET API.
Uses element trees rather than images for more stable locators.
Good fit for legacy and enterprise Windows desktop apps.
Integrates with .NET test frameworks and CI workflows.
How it compares to Airtest + Poco:
For Windows desktop testing where UIA is available, White can be more stable than image matching and reduce flakiness.
Airtest + Poco can still help when UIA is insufficient or when combining desktop flows with mobile or CV-heavy tasks.
Choose White if your primary need is Windows desktop automation in C#/.NET with native element access.
12) Winium
What it is: Winium is a Selenium-based automation framework for Windows desktop apps. It aims to bring WebDriver-style interactions to Windows, though development is less active.
Core strengths:
WebDriver-like protocol familiar to Selenium users.
Targets Windows applications using automation peers where available.
Integrates with existing Selenium-style infrastructure and patterns.
Can run in CI and reuse WebDriver client libraries.
How it compares to Airtest + Poco:
For teams already invested in WebDriver paradigms and targeting Windows, Winium can be a low-friction step. However, maintenance activity is limited.
Airtest + Poco can bridge Windows and mobile with CV support. If you need reliable, ongoing support and you have complex Windows UI needs, consider whether White or other actively maintained tools are a better long-term choice.
Winium may suit legacy needs; validate compatibility with your specific app tech stack before committing.
Things to Consider Before Choosing an Airtest + Poco Alternative
Application under test and platform scope:
Locator strategy and UI model:
Language ecosystem and team skills:
Ease of setup and execution speed:
CI/CD integration and parallelization:
Debugging and reporting:
Stability and maintainability:
Community, maintenance, and ecosystem:
Cost and infrastructure:
Conclusion
Airtest + Poco remains a strong choice for teams that need cross-platform automation with a heavy emphasis on image-based interaction and support for game-like or custom-rendered UIs. Its Python foundation, CI/CD friendliness, and the availability of Airtest IDE have made it popular among mobile and gaming QA teams.
However, one size rarely fits all. If you build Flutter apps, Appium Flutter Driver provides more stable, widget-level selectors. If you are focused on web, tools like Capybara, Selene, Serenity BDD, or Playwright Component Testing offer cleaner idioms, richer reporting, and fewer flakiness challenges than CV-based approaches. For Android system-level testing, UI Automator shines. On Windows desktop, White and Winium align with .NET and WebDriver paradigms. Maestro stands out for teams that want fast, declarative mobile flows without deep scripting.
The best choice depends on your platform mix, preferred language, desired test style, and operational constraints. Many high-performing QA organizations use a hybrid toolbox: a web-first framework for browser apps, a mobile-first runner for iOS/Android, and CV-based tooling for niche or game-specific flows. Start by mapping your application surfaces and stability needs, then pick the smallest set of tools that reliably covers them with maintainable tests and clear reporting.
Sep 24, 2025