Címke: Espresso

  • Android applikáció tesztelése – kérdések

    Induljunk ki onnan, hogy ebben igazából nincs tapasztalatom, bár nem érzem annyira elveszettnek magam a témába, hogy ha kell, akkor rövid időn belül fel ne tudnám venni a fonalat. Első lépés pont az AI megkérdezése volt, ami rögtön ad pár kiindulási pontot erre vonatkozóan.

    Egyébként a héten olvastattam, kérdezgettem, és nekem azt tűnt fel, hogy Android Stúdió igen hasznos IDE ehhez, illetve emulátorokra érdemes előfizetni, vagy épp hozzákötött eszközön futtatni a tesztet, de az sem ördögtől való, ha valaki saját farmot épít erre. Szóval van benne mozgástér és kihívás…

    Na de nézzük, mit ír az AI:

    Az androidos alkalmazások automatizált tesztelésére számos kiváló eszköz és keretrendszer létezik, amelyek eltérő filozófiát (natív vs. cross-platform), nyelvet és architektúrát képviselnek.

    1. Espresso (Natív – Google)

    Az Espresso a Google hivatalos, natív UI tesztelési keretrendszere Androidra. Fejlesztők számára készült (white-box tesztelés), és szorosan együttműködik az alkalmazás kódjával.

    • Előnyök:
      • Villámgyors: Közvetlenül az alkalmazás folyamatán belül fut, automatikusan szinkronizál a fő szálakkal (UI thread) és az animációkkal.
      • Stabil: Ritkán fordul elő „vakság” vagy időzítési hiba (flakiness), mert tudja, mikor éri el az alkalmazás a stabil állapotot.
      • Kiváló integráció: Android Studio-barát, Kotlinban vagy Java-ban íródik.
    • Hátrányok:
      • Csak Android támogatás (iOS-re nem jó).
      • Fejlesztői tudást igényel (white-box), a forráskód ismerete szükséges hozzá.
      • Nem tud kilépni az applikációból (pl. nem tudja tesztelni a külső rendszerbeállításokat vagy a notification bar-t – bár erre ott a UI Automator).

    Példa (Kotlin):

    Kotlin

    onView(withId(R.id.usernameInput))
        .perform(typeText("felhasznalo"), closeSoftKeyboard())
    onView(withId(R.id.loginButton))
        .perform(click())
    onView(withId(R.id.welcomeTextView))
        .check(matches(withText("Üdvözlünk!")))
    

    2. UI Automator (Natív rendszer szintű – Google)

    A Google másik natív eszköze, amelyet kifejezetten cross-app és rendszerszintű interakciókra (pl. értesítések, kamera, beállítások, háttérben futó folyamatok) terveztek.

    • Előnyök:
      • Képes kezelni az operációs rendszer elemeit is (pl. Wi-Fi kikapcsolása, értesítési sárkány lehúzása).
      • Nem igényel forráskódot (black-box).
    • Hátrányok:
      • Lassabb, mint az Espresso.
      • Önmagában nehézkes komplex alkalmazás-logikák tesztelésére.

    Példa (Kotlin):

    Kotlin

    val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
    val settingsButton = device.findObject(By.text("Beállítások"))
    settingsButton.click()
    

    3. Appium (Cross-platform ipari szabvány)

    Az Appium a legelterjedtebb, nyílt forráskódú, cross-platform mobiltesztelési keretrendszer. A WebDriver protokollra épül, így szinte bármilyen nyelven írhatók benne tesztek (TypeScript/JavaScript, Python, Java, C#).

    • Előnyök:
      • Multiplatform: Ugyanaz a tesztkód futtatható Androidon és iOS-en is.
      • Nyelvi rugalmasság: Nem vagy kötve a Kotlinhoz; írhatod JavaScriptben vagy Pythonban is.
      • Hatalmas ökoszisztéma és közösség.
    • Hátrányok:
      • Lassabb: A kód egy külső szerveren (Appium Server) keresztül kommunikál a mobileszközzel (távoli hívások).
      • Flaky lehet: Könnyen előfordulhatnak időzítési hibák, ha a várakozások (waits) nincsenek precízen beállítva.
      • Nehézkes beüzemelés és környezet-konfiguráció (Android SDK, Appium driverek).

    Példa (TypeScript / WebDriverIO):

    JavaScript

    await $('~usernameInput').setValue('felhasznalo');
    await $('~loginButton').click();
    await expect($('~welcomeTextView')).toHaveText('Üdvözlünk!');
    

    4. Maestro (A modern kihívó)

    A Maestro a Mobile.dev által készített modern, rendkívül népszerű E2E (End-to-End) mobil tesztelési keretrendszer. YAML alapú, egyszerű leíró nyelvvel dolgozik.

    • Előnyök:
      • Hihetetlenül gyors és stabil: Beépített okos várakozásokkal rendelkezik, így szinte teljesen kiküszöböli a „flaky” teszteket.
      • Egyszerű szintaxis: Nem kell programozónak lenni a megírásához, olvasható YAML fájlokból áll.
      • Kiváló fejlesztői élmény (CLI eszközök, azonnali visszajelzés).
    • Hátrányok:
      • Kevésbé rugalmas extrém összetett, programozói logikát igénylő teszteknél, mint egy teljes értékű kódalapú keretrendszer.
      • Relatív új ökoszisztéma az Appiumhoz képest.

    Példa (YAML):

    YAML

    appId: com.example.app
    ---
    - launchApp
    - tapOn: "Felhasználónév"
    - inputText: "felhasznalo"
    - tapOn: "Bejelentkezés"
    - assertVisible: "Üdvözlünk!"
    

    5. Detox (React Native fókuszú)

    A Detox egy „gray-box” tesztelési keretrendszer, amelyet kifejezetten a React Native alapú mobilalkalmazásokhoz optimalizáltak, de natív appokhoz is használható.

    • Előnyök:
      • Közvetlenül szinkronizálódik a React Native JavaScript hídjával és az aszinkron műveletekkel, így rendkívül stabil.
      • Gyorsabb végrehajtás, mint az Appiumé.
    • Hátrányok:
      • Magasabb belépési küszöb a konfigurációhoz.
      • Elsősorban React Native környezetben mutatja meg igazi erejét.

    Összehasonlító táblázat

    EszközTípusFő programozási nyelvElőnyHátrány
    EspressoNatív (White-box)Kotlin / JavaVillámgyors, stabilCsak Android, forráskód kell hozzá
    UI AutomatorNatív (Rendszerszintű)Kotlin / JavaRendszer- és appközi tesztekLassabb, régebbi API
    AppiumCross-platformJS, Python, Java, stb.Keresztplatform, soknyelvűLassabb hálózati hívások, nehéz setup
    MaestroModern E2EYAMLGyors, rendkívül egyszerű olvasniKevesebb programozói rugalmasság
    DetoxGray-boxJavaScript / TypeScriptKiváló React Native-hezKomplex konfiguráció