Detox vs Maestro 2026: E2E testování React Native pro reálné týmy

Aktualizováno: 22. června 2026

Pro nové React Native projekty v roce 2026 doporučuju začít s Maestrem. Nastavení trvá desítky minut místo dní, testy se píšou v YAML a Hermes i Nová architektura fungují bez konfigurace. Detox si necháme pro zralé týmy, které už mají stabilní CI pipeline, potřebují deterministickou synchronizaci s nativními moduly a nevadí jim náklady na údržbu. Šest aplikací mě naučilo, že volba E2E nástroje rozhoduje o tom, jestli vám testy pomáhají, nebo jestli je každé pondělí někdo přepisuje.

• Maestro 1.40 (květen 2026) podporuje Hermes, Fabric i Bridgeless mode bez dalšího setupu. Detox vyžaduje vlastní konfiguraci pro Novou architekturu.
• Maestro testy se píšou v YAML. Průměrný nový projekt zruční CI běh do 30 minut, u Detoxu počítejte se 4 až 8 hodinami počátečního ladění.
• Detox stále vede v rychlosti běhu na zralých projektech (až 2× rychlejší než Maestro Cloud) a v deterministické synchronizaci s nativním kódem.
• Maestro Cloud nabízí paralelizaci a real-device farming, Detox tradičně běží na simulátoru nebo emulátoru ve vlastním CI.
• Pro Expo a EAS Build je Maestro výrazně méně bolestivý. EAS Workflows má nativní integraci od dubna 2026.
• Flakiness v Detoxu je často chyba synchronizace s animacemi, v Maestru častěji načasování assertů. Oba jdou stabilizovat, ale rozdílnými technikami.

Detox vs Maestro: rychlé srovnání

Než se pustíme do podrobností, tady je side-by-side srovnání obou nástrojů podle dimenzí, které mi v praxi rozhodují, od nákladů na první test po chování v CI. Čísla pro setup time a průměrný čas běhu testu jsou z mých vlastních projektů (čtyři produkční aplikace v roce 2026, počet E2E testů 30 až 120). Oficiální dokumentaci najdete v Maestro docs a Detox docs.

Kritérium	Maestro 1.40	Detox 20.x
Jazyk testů	YAML (deklarativní)	JavaScript/TypeScript
Setup nového projektu	~30 minut	4 až 8 hodin
Podpora Nové architektury (Fabric/TM)	Out-of-the-box	Vyžaduje konfiguraci
Synchronizace s aplikací	Heuristická (čeká na „quietness“)	Deterministická (waitForIdle)
Rychlost běhu (zralý projekt)	Střední	Vyšší (až 2×)
Cloud farming	Maestro Cloud (placený, paralelizace)	Vlastní CI, BrowserStack/Sauce
Expo / EAS integrace	Nativní (EAS Workflows)	Funguje s ejected/dev-clientem
Test recording	Maestro Studio (vizuální)	Z větší části ručně
Křivka učení	Mírná	Strmá

Proč je Maestro rychlejší na nastavení než Detox?

Maestro pracuje úplně mimo váš JavaScript bundle. Je to externí proces, který komunikuje s aplikací přes accessibility API systému (iOS Accessibility, Android UIAutomator). To znamená, že nemusíte nic linkovat, nic patchovat ani upravovat AppDelegate nebo MainApplication. Stáhnete CLI, spustíte aplikaci v simulátoru a Maestro ji vidí. Tečka.

Detox naproti tomu žije uvnitř vaší aplikace. Potřebuje nativní modul, který musí být zalinkovaný do iOS i Androidu, a host server, který si spravuje vlastní React Native bridge. To dává Detoxu jeho deterministickou synchronizaci: ví, kdy je JS thread idle, kdy doběhly fetch requesty, kdy se dokončily animace. Cena je ale vysoká. Jakákoli změna v node_modules nebo v nativní toolchain (Xcode update, AGP bump, Hermes verze) může setup rozbít a strávíte půl dne hledáním, proč detox build spadne s nesrozumitelnou chybou v Pods.

Honestly, v praxi to vypadá takhle: u poslední aplikace, kterou jsme rozjížděli (Expo SDK 53, React Native 0.79, asi 80 000 řádků TS), trvalo nasazení Maestra včetně tří smoke testů a CI integrace 35 minut. Detox jsme dělali souběžně jako experiment a trvalo to dva dny, protože jsme narazili na Hermes-specific issue s waitForIdle ve Fabric režimu. Pokud se na to chcete podívat zevnitř, doporučuju projít článek o Nové architektuře React Native v roce 2026, který popisuje, co všechno se ve Fabric mění a proč to Detox bolí.

Podporuje Detox Novou architekturu React Native?

Krátká odpověď: ano, ale s hvězdičkou. Detox 20.0 (leden 2026) přinesl oficiální podporu pro Bridgeless mode a Fabric renderer. Wix tým ji označuje za „production-ready“, ale v reálných projektech narazíte na hrany, zejména pokud používáte vlastní TurboModules nebo Reanimated 4.

Konkrétní problémy, na které jsem narazil:

• Synchronizace s Fabric: Detox čeká na „idle“ stav, ale Fabric scheduler může mít pending tasks, které Detox nevidí. Výsledkem jsou občasné race conditions u rychlých přechodů obrazovek.
• Reanimated 4 worklets: animace běžící na UI threadu mimo JS runtime nejsou ve waitForAnimation API plně reflektované. Workaround je waitFor().toBeVisible().withTimeout(2000), ale je to víc kódu.
• TurboModules s async metodami: pokud váš nativní modul vrací Promise, Detox občas dokončí test, než modul stačí emitnout výsledek.

Maestro tyhle problémy nemá, protože o React Native architektuře neví. Jenom čte výsledný UI tree. Když obrazovka přestane „blikat“ (definice quietness), je hotová. Je to méně přesné, ale ironicky stabilnější u Fabric apps. Pro detailní rozbor toho, jak Fabric mění synchronizační model, viz oficiální React Native 0.76 release post o New Architecture.

První E2E test v Maestru: krok za krokem

Ukážu vám reálný flow z aplikace, kterou teď udržuju. Cíl: ověřit, že po loginu vidíme home screen a název uživatele. Předpokládám, že máte aplikaci spuštěnou v simulátoru.

1) Instalace CLI

curl -fsSL "https://get.maestro.mobile.dev" | bash
maestro --version
# 1.40.2

2) Test flow v YAML. Uložte jako .maestro/login.yaml:

appId: com.example.myapp
---
- launchApp:
    clearState: true
- assertVisible: "Sign in"
- tapOn:
    id: "email-input"
- inputText: "[email protected]"
- tapOn:
    id: "password-input"
- inputText: "Secret123!"
- tapOn: "Continue"
- assertVisible:
    id: "home-screen"
    timeout: 10000
- assertVisible: "Welcome, Jake"

3) Spuštění

maestro test .maestro/login.yaml

To je všechno. Žádný build script, žádný host runner, žádné jest. Maestro otevře aplikaci, najde elementy podle testID (z atributu id) nebo viditelného textu a kroky vyhodnotí. Pokud chcete authoring přes UI, spusťte maestro studio. Otevře se browser s live náhledem simulátoru a kroky můžete klikat.

Maestro také podporuje scripted kroky v JavaScriptu pro složitější logiku (např. generování OTP tokenu z TOTP secretu), ale 95 % testů zvládnete v čistém YAML. To je část, kterou QA inženýři, ne devs, v praxi opravdu píšou sami.

První E2E test v Detoxu: krok za krokem

Stejný flow v Detoxu vypadá výrazně robustněji, ale i náročněji. Zde předpokládám, že máte React Native CLI projekt s Detox 20.

1) Instalace a konfigurace

npm install --save-dev detox @types/detox jest
npx detox init -r jest

# upraví .detoxrc.js, vytvoří e2e/ adresář
# Pro iOS:
cd ios && pod install && cd ..
detox build --configuration ios.sim.debug

2) Konfigurace v .detoxrc.js:

module.exports = {
  testRunner: { args: { config: 'e2e/jest.config.js' } },
  apps: {
    'ios.debug': {
      type: 'ios.app',
      binaryPath: 'ios/build/Build/Products/Debug-iphonesimulator/MyApp.app',
      build: 'xcodebuild -workspace ios/MyApp.xcworkspace -scheme MyApp -configuration Debug -sdk iphonesimulator -derivedDataPath ios/build',
    },
  },
  devices: {
    simulator: { type: 'ios.simulator', device: { type: 'iPhone 15' } },
  },
  configurations: {
    'ios.sim.debug': { device: 'simulator', app: 'ios.debug' },
  },
};

3) Test soubor e2e/login.test.ts:

describe('Login flow', () => {
  beforeAll(async () => {
    await device.launchApp({ newInstance: true });
  });

  it('logs in and shows home', async () => {
    await expect(element(by.text('Sign in'))).toBeVisible();
    await element(by.id('email-input')).typeText('[email protected]');
    await element(by.id('password-input')).typeText('Secret123!');
    await element(by.text('Continue')).tap();
    await waitFor(element(by.id('home-screen')))
      .toBeVisible()
      .withTimeout(10000);
    await expect(element(by.text('Welcome, Jake'))).toBeVisible();
  });
});

4) Spuštění

detox test --configuration ios.sim.debug

Test je expresivnější a má skutečné assertions, ale za cenu nezanedbatelného boilerplate. Build krok trvá u větších aplikací 3 až 8 minut a musí proběhnout pokaždé, když měníte nativní kód. A tady je důvod, proč mám u zralých projektů Detox rád: waitFor a expect chain dává deterministické chování, které u flaky scenarios oceníte.

Který nástroj funguje lépe s EAS Build a CI?

Když pracujete s Expo a EAS, Maestro vyhrává s přehledem. Od dubna 2026 má EAS Workflows nativní step pro Maestro, který stáhne build, spustí simulátor a běh testů provede v jednom YAML souboru bez vlastní orchestrace. U Detoxu musíte řešit, jak dostat ejected build do CI image a jak ho propojit s Detox runnerem. Ne nemožné, ale dvojnásobek konfigurace.

Pro bare React Native CLI s GitHub Actions je situace vyrovnanější. Detox má léty ozkoušené GitHub Actions appendixy a pro paralelizaci přes --workers 3 dnes funguje spolehlivě. Maestro paralelizuje primárně přes Maestro Cloud, což je placená služba od mobile.dev, která vám dá farm zařízení a smart retry. Pokud máte rozpočet, je to nejlepší cesta, jakou znám. Pokud ne, můžete Maestro spouštět ve více matrix jobs s různými flow soubory.

Pro CI strategii doporučuju i článek o debugování React Native pomocí DevTools a Hermes Profileru, protože když E2E test selže v CI, často není problém v testu, ale v aplikaci pod ním, a Hermes profile dump bývá nejrychlejší cesta k root cause.

Jak řešit flaky testy v React Native?

Flakiness je důvod, proč většina týmů E2E testy nakonec vypne. Ale způsob, jak ji řešit, se v Detoxu a Maestru liší.

Flakiness v Detoxu

V Detoxu jsou flaky testy téměř vždycky chyba synchronizace. Nejčastější příčiny:

• Animace běžící mimo JS thread (Reanimated worklets, native driver). Řešení: device.disableSynchronization() kolem kritického bloku a explicitní waitFor.
• Nekonečné timery. setInterval, který nikdy nekončí, drží Detox synchronizaci nahoře. Detox čeká, až bude vše idle, a nedočká se. Řešení: device.setURLBlacklist() nebo přepnout timer na requestAnimationFrame.
• WebSocket nebo dlouhá HTTP spojení: stejný problém. Detox čeká na idle network.

Flakiness v Maestru

Maestro nepoužívá synchronizaci s aplikací, takže problémy jsou jiné:

• Timing assertů. Maestro čeká na „quietness“ v UI tree, ale pokud máte stránku, která pomalu načítá data, je třeba explicitní timeout na assertu.
• Race conditions u rychlých přechodů. Po tapOn hned assertVisible může chytit ještě starou obrazovku. Řešení: přidat extendedWaitUntil.
• Network calls v pozadí. Maestro netuší, že čekáte na API. Použijte explicitní assertVisible na element, který se objeví po response.

V obou nástrojích platí jedno pravidlo: nepoužívejte sleep. Vždycky čekejte na konkrétní podmínku (visible element, text, state). Sleeps maskují skutečný race condition a v CI se vždycky chytí.

Kdy zvolit Detox, kdy Maestro?

Tady je můj rozhodovací strom, ten samý, který jsem použil na posledních třech projektech. Krátký a opakovatelný, ne dlouhá analýza per projekt.

Zvolte Maestro, pokud:

• Začínáte nový projekt v roce 2026 nebo přidáváte E2E do existujícího bez E2E pokrytí.
• Používáte Expo a EAS Build / EAS Workflows.
• Máte v týmu QA inženýry nebo product manažery, kteří mají psát testy.
• Vaše aplikace běží na Nové architektuře a používáte Reanimated 4 nebo vlastní Fabric komponenty.
• Chcete cloud farming a paralelizaci bez správy vlastní device farmy.

Zůstaňte u Detoxu (nebo přejděte na něj), pokud:

• Máte už zralou Detox suite s 50+ testy a CI pipeline, která se chová stabilně. Migrace by nepřinesla hodnotu odpovídající úsilí.
• Vaše testy hodně závisí na deterministické synchronizaci s nativními moduly, např. testy bluetooth scanning, biometric auth, push notification flows.
• Tým má hlubokou JavaScript/TypeScript expertizu a YAML mu vadí pro composition a reuse.
• Hostujete vlastní CI infrastrukturu a placená Maestro Cloud je out-of-budget.

Pro porovnání s dalšími state management nástroji, které dobře fungují s testovacími strategiemi, viz průvodce Zustand v React Native. Zustand store je triviální na resetování mezi testy, což je další tichá výhoda při psaní E2E suite.

Pokud uvažujete o migraci, můj postup je takový: nechte starou Detox suite běžet jako safety net, paralelně napište deset nejdůležitějších flow v Maestru a dva sprinty sledujte stabilitu obou. Když Maestro suite drží > 95 % pass rate na release buildu, vypněte Detox. Bez velkého třesku, bez celodenních diskuzí.

Časté dotazy

Je Maestro v roce 2026 production-ready pro velké aplikace?

Ano. Maestro od verze 1.30 (vydáno listopad 2025) podporuje paralelizaci, retry strategie i custom JavaScript hooks. Firmy jako Shopify, Linear nebo Klarna na něm staví E2E suites s tisíci testy. Pro > 300 testů ale zvažte Maestro Cloud pro sharding.

Je Detox stále aktivně vyvíjený?

Ano. Wix vydal Detox 20.x v lednu 2026 s podporou Bridgeless modu a Fabric. Tempo releasů je pomalejší než dřív, ale projekt není mrtvý. Má aktivní maintainery a komerční podporu.

Můžu používat oba nástroje současně?

Technicky ano a v migračním okně to dává smysl. Dlouhodobě je to ale dvojnásobná údržba. Testy se rozjedou, oba runners potřebují vlastní CI joby a vy strávíte čas synchronizací assertions místo psaní nových testů.

Podporuje Maestro real-device testování?

Ano, na lokále i na Maestro Cloud. Stačí připojit iOS zařízení přes USB (nebo wireless debugging) nebo mít Android zapnutý ADB debugging. Maestro Cloud nabízí farm reálných zařízení s pluginy pro nastavení lokace, sítě a accessibility settings.

Jak rychlé jsou Maestro testy ve srovnání s Detoxem?

Detox je u zralého projektu typicky 1,5 až 2× rychlejší per test, protože nepotřebuje čekat na quietness a má deterministickou synchronizaci. Maestro to v praxi dohání paralelizací přes Maestro Cloud, takže celkový wall-clock čas CI běhu bývá srovnatelný.