Tesztelés a mobilfejlesztésben: mi ez, milyen típusok és hogyan szervezzük

Tesztelési szintek: Unit, Integration, E2E

Egységtesztelés

Az egységtesztek a mobilalkalmazás-tesztelés alapjai. Ellenőrzik a kód legkisebb egységét — egyetlen függvényt, metódust vagy osztályt a rendszer többi részétől elkülönítve. A mobilfejlesztésben az egységtesztek JUnit (Android) és XCTest (iOS) nyelven íródnak. Egy jó egységtesztnek gyorsnak, függetlennek és ismételhetőnek kell lennie — nem függhet a hálózattól, adatbázistól vagy UI-összetevőktől. Az elkülönítéshez tesztduplumokat használnak: mock-okat, stub-okat és fake-eket.

Mockito (Java/Kotlin) és MockK (Kotlin-first) népszerű könyvtárak mock objektumok létrehozásához Androidon. iOS-en az OCMock, Cuckoo vagy manuális protokollok használatosak. Szabály: az egységteszteknek az üzleti logikát és az adatmodelleket kell lefedniük. Az UI-tesztek nem duplikálhatják az egységteszteket — ezek a felhasználó és a felület közötti interakciót ellenőrzik.

Integrációs tesztelés

Az integrációs tesztek az összetevők közötti interakciót ellenőrzik: adatbázissal rendelkező tár, ViewModel API-szolgáltatással, navigáció a képernyők között. Az egységtesztektől eltérően az integrációs tesztek valós vagy valósághű függőségeket használnak (pl. memórián belüli adatbázis vagy mock szerver). Robolectric egy keretrendszer Android-tesztek futtatásához JVM-en emulátor nélkül, ami tízszeresére gyorsítja az integrációs teszteket.

A pillanatkép-tesztek (Golden Tests) az integrációs tesztek egy speciális típusa, amelyek egy renderelt UI-összetevőt egy referenciaképhez (pillanatkép) hasonlítanak. Ha a megjelenés megváltozik, a teszt elbukik — a fejlesztő látja, mi változott. A Facebook SnapshotTestCase (iOS) és a Shot (Android) népszerű eszközök a pillanatkép-teszteléshez.

E2E és UI tesztelés

Az E2E-tesztek (végponttól végpontig) a teljes felhasználói forgatókönyvet ellenőrzik az elejétől a végéig: alkalmazás indítása, bejelentkezés, művelet végrehajtása, eredmény ellenőrzése. Az UI-tesztek az E2E egy részhalmaza, amely a felületre összpontosít. Eszközök: Espresso (Android), XCUITest (iOS), Detox (React Native). Az E2E-tesztek a leglassabbak, ezért külön futnak a CI-n — általában éjszakai buildekben.

iOS-eszközök: XCTest és XCUITest

XCTest

XCTest az Apple beépített keretrendszere mobilalkalmazások egységteszteléséhez. Az XCTestRunner teszteket futtat a szimulátoron vagy egy valós eszközön. A tesztek az XCTestCase-ből származnak, setUp és tearDown függvényeket tartalmaznak az előkészítéshez és tisztításhoz. Az XCTest tartalmazza az XCTAssert-et ellenőrzésekhez (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) és az XCTWaiter-t aszinkron műveletek várakozásához.

Példa egy egyszerű XCTest-tesztre: User modell létrehozása, inicializálás helyességének, névformázásának és életkor számításának ellenőrzése. Code Coverage az Xcode-ban megmutatja, mely kódsorokat fedik le a tesztek — a kereskedelmi projektek célja: az üzleti logika legalább 70–80%-os lefedettsége. Az XCTest integrálva van az Xcode Serverrel és a CI-rendszerekkel az xcodebuild test segítségével.

XCUITest

XCUITest az Apple keretrendszere UI-teszteléshez. Akadálymentesítési azonosítókon keresztül működik: az XCUIElementQuery gombokat, beviteli mezőket, táblázatokat talál címke, azonosító vagy típus alapján. Az XCUITest rögzíti a műveletek sorrendjét (record/playback) és tesztkódot generál. Fontos: minden UI-elemnek rendelkeznie kell accessibilityIdentifier-rel a tesztek stabil működéséhez.

Android-eszközök: JUnit, Espresso, Robolectric

JUnit és Mockito

JUnit az alapvető keretrendszer mobilalkalmazások moduláris teszteléséhez Java/Kotlin nyelven. Androidon a JUnit 4 (legutóbbi stabil verzió 4.13.2) és az új projektekhez JUnit 5 használatos. Mockito egy könyvtár mock objektumok létrehozásához: when(mock.method()).thenReturn(value) — egy szabványos minta a tesztelt osztály függőségektől való elkülönítésére.

Példa JUnit-tesztre Androidhoz:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso és UI Automator

Espresso a Google keretrendszere Android UI-tesztekhez. Az Espresso automatikusan szinkronizál az UI-szállal: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Az Espresso könnyen írható és stabil a beépített tétlen állapot várakozásnak köszönhetően. UI Automator egy keretrendszer alkalmazások közötti tesztekhez, amely képes interakcióba lépni rendszerelemekkel (engedélypárbeszédpanelek, értesítési panel).

Platformfüggetlen eszközök: Detox, Appium

Detox React Native-hoz

Detox egy szürkedobozos E2E keretrendszer React Native mobilalkalmazások teszteléséhez a Wix-től. A Detox mindkét platformon működik egyetlen tesztkódbázisból, a Espresso (Android) és XCUITest (iOS) használatával a motorháztető alatt. A Detox automatikusan megvárja, amíg az alkalmazás tétlen lesz (nincs animáció, hálózati kérelem, időzítő), és csak azután hajtja végre a következő műveletet.

Appium

Appium egy univerzális platformfüggetlen keretrendszer, amely támogatja az Android, iOS, Web és hibrid alkalmazásokat. Az Appium a WebDriver protokollt használja, és bármilyen programozási nyelvet támogat (Java, Python, JS, Ruby). Az Appium Server HTTP-szerverként működik, amely parancsokat natív UI Automator / XCUITest parancsokká fordít. Az Appium fő hátránya a sebesség: a tesztek lassabban futnak, mint a natív Espresso vagy XCUITest.

TDD és BDD: tesztelési módszertanok

TDD: Test-Driven Development

TDD egy mobilalkalmazás-tesztelési módszertan, ahol a tesztet a megvalósítási kód előtt írják meg. A Red-Green-Refactor ciklus: (1) írj egy tesztet, ami elbukik (Red), (2) írj minimális kódot a teszt teljesítéséhez (Green), (3) refaktoráld a kódot a teszt teljesítésének megtartása mellett. A TDD 100%-os tesztlefedettséget biztosít az új funkciókhoz és tiszta architektúrát, mivel a teszt a követelmény első specifikációja.

BDD: Behaviour-Driven Development

BDD a TDD kiterjesztése, ahol a teszteket természetes nyelven írják Given-When-Then formátumban. Given (kontextus) — When (művelet) — Then (várt eredmény). A BDD-tesztek érthetőek a csapat minden tagja számára: fejlesztők, tesztelők, elemzők és ügyfelek. Mock vs Stub vs Fake: A Mock ellenőrzi az interakciót (hogy a metódust meghívták-e), a Stub rögzített adatokat ad vissza, a Fake egy egyszerűsített működő megvalósítás (pl. memórián belüli adatbázis). Az IT Sectr-nél a TDD-t kritikus üzleti logikához, a BDD-t pedig elfogadási forgatókönyvekhez használjuk.

Tesztduplumok az objektumok általános neve, amelyek a valódi függőségeket helyettesítik a tesztekben. Négy típus létezik: Dummy (objektum paraméterek kitöltéséhez, nem használt), Stub (megadott értékeket ad vissza), Spy (rögzíti a hívásokat ellenőrzéshez), Mock (előre meghatározza a várt hívásokat). A különbség megértése kritikus fontosságú a helyes teszttervezéshez.

CI/CD és Device Farm

Teszt automatizálás CI/CD-ben

CI/CD — Folyamatos Integráció és Folyamatos Szállítás: a mobilalkalmazások automatikus építésének és tesztelésének gyakorlata minden kódváltozásnál. A mobilfejlesztésben a CI/CD pipeline tartalmazza: lintelést, egységteszteket, integrációs teszteket, APK/IPA-építést és UI-teszteket. GitHub Actions és a Bitrise népszerű platformok a mobil CI/CD-hez. A teszteknek gyorsan kell futniuk: egységtesztek 1–2 perc alatt, integrációs tesztek 5–10 alatt, UI-tesztek 15–30 perc alatt.

Device Farm

Device Farm valódi eszközök farmja a teszteléshez. A Firebase Test Lab (Android) és az Xcode Cloud (iOS) felhőhozzáférést biztosít több száz eszközmodellhez. A Device Farm olyan problémákat tár fel, amelyek az emulátorokon nem láthatók: különböző képernyőméretek, teljesítmény régebbi eszközökön, kompatibilitási problémák. Az IT Sectr-nél rendszeresen használjuk a Firebase Test Lab-ot Androidhoz és az Xcode Cloud-ot iOS-hez.