Minőség · Tesztelés
A unit teszt megtérül – a UI-teszt pedig valódi eszközre való
A tesztelés rendszerint az első tétel, amit kihúznak a mobilos büdzséből – az értéke ugyanis láthatatlan, egészen addig a napig, amíg baj nem lesz. Megmutatjuk, hogyan gondolkodunk a tesztpiramisról a gyakorlatban: az üzleti logika unit tesztjeitől az Appiummal automatizált, device farmon futó UI-tesztekig.
Az érv, ami az ügyfelet tényleg érdekli
A tesztelés mellett nem az elvont „minőség” a legjobb érv, hanem a sebesség – csak nem most, hanem később. Egy teszt nélküli appot az első hónapban könnyű módosítani, a tizenkettedikben viszont már ijesztő: bármelyik változtatás elronthat valamit, amit senki nem lát, ezért minden kiadás előtt kézzel kell végigkattintani az egészet, így a kiadások ritkulnak, egyre nagyobbak és egyre kockázatosabbak lesznek. A tesztek megfordítják ezt a görbét. Miattuk lehet egy érett kódbázisból is hétről hétre, nyugodt szívvel kiadni.
Az Invoice Gurunál ezt a saját bőrünkön tapasztaltuk: egy élesben futó számlázóapp részleges újraírásába csak akkor felelős döntés belevágni, ha tesztek rögzítik, minek nem szabad megváltoznia – az ügyfelek, a tételek és az áfával együtt helyesen számolt végösszegek. A tesztek ott nem plusz költséget jelentettek, hanem azt a biztosítókötelet, ami nélkül a projekt el sem indulhatott volna.
Unit tesztek: olcsók, gyorsak, és arra a logikára célzunk velük, ami számít
Nem kergetünk lefedettségi százalékokat. A unit teszteket oda irányítjuk, ahol egy észrevétlen hiba valódi pénzbe vagy bizalomba kerül: ár- és áfaszámítás, dátum- és pénznemkezelés, adattranszformációk, állapotátmenetek. Ráadásul pont itt a legolcsóbb a unit teszt: felület nélküli, tiszta logika, ami minden módosításnál ezredmásodpercek alatt lefut.
Részben ezért van az, hogy az architektúra és a tesztelés ugyanaz a beszélgetés. Az a logika, ami providerekben, repository-kban és service-ekben él, nem pedig a widgetek belsejében, olyan logika, amihez egy teszt hozzáfér. Ha egy kódbázist nehéz unit tesztelni, az szinte mindig architektúraproblémát jelez, nem tesztelési problémát.
UI-tesztek device farmon: mert az emulátor hazudik
A unit szint fölött már más a kérdés: nem az, hogy helyes-e a logika, hanem az, hogy működik-e az app azon a telefonon, amit a felhasználó a kezében tart – és erre egyetlen emulátor sem ad megbízható választ. Az Android-fragmentáció nem mítosz: a gyártók saját felületet húznak az Androidra, az agresszív akkumulátorkezelők kilövik a háttérfolyamatokat, a képernyőméretek és -sűrűségek széles skálán szórnak, a régi OS-verziók pedig évekig forgalomban maradnak. Az iOS kíméletesebb, de nem kivétel: a notch, a dinamikus betűméret és az OS-frissítések rendre eltörik azokat az elrendezéseket, amelyek a szimulátorban még hibátlannak tűntek.
Ezért automatizáljuk az end-to-end UI-tesztjeinket Appiummal, és ezért futtatjuk őket device farmon: valódi, fizikai eszközökön, több gyártó, képernyőméret és OS-verzió mátrixán. Az Appium úgy használja az appot, ahogy egy felhasználó: koppint, húz, szöveget ír be, majd ellenőrzi, mi jelenik meg ténylegesen a képernyőn. A kritikus folyamatok – a bejelentkezés, a fő értékteremtő út, a fizetés – kiadás előtt végigfutnak az eszközmátrixon, nem pedig egy tesztelő kattintja végig őket checklist alapján azon a telefonon, ami épp az asztalon hevert.
Mit automatizálunk – és mit szándékosan nem
Az automatizálásnak karbantartási költsége van, ezért az e2e-készletet szűkre és értékesre szabjuk: csak azok a folyamatok kerülnek bele, ahol egy regresszió incidens lenne, nem pusztán kellemetlenség. Ez alatt a widget tesztek fedik le az érdemi logikát tartalmazó képernyőket, a piramis zömét pedig a unit tesztek adják. A felfedező tesztelés – a furcsa, kreatív, emberi fajta – emberi feladat marad; az automatizálás nem kiváltani akarja a tesztelőket, hanem felszabadítani erre.
A kiadási szabály, ami mindebből következik, egyszerű: a pipeline lefuttatja a tesztkészletet, a device farm a kritikus folyamatokat, és ha bármi piros, a kiadás áll. Határidő esetén sincs kivétel – pont a határidő az a pillanat, amikor ez a fegyelem megtérül.
Tanulságok
- ✓A teszt nem az első hónapban befizetett adó, hanem az, amitől a tizenkettedik hónapban is gyors és nyugodt marad a kiadás.
- ✓A unit teszteket arra a logikára célozd, ahol pénz vagy bizalom forog kockán – árazás, áfa, dátumok, adattranszformációk –, ne egy lefedettségi százalékra.
- ✓A nehezen tesztelhető kód architektúraproblémára utal; a tesztelhető logika a widgeteken kívül, providerekben és service-ekben él.
- ✓Az emulátor nem a valóság – a kritikus folyamatok UI-tesztjeit Appiummal, valódi eszközökön, a teljes fragmentációs mátrixon futtasd.
- ✓Az e2e-készlet legyen kicsi és szigorú: azt automatizáld, ahol a regresszió incidens, és a piros eredmény állítsa meg a kiadást.
Olyan terméken dolgozol, ahol ez számít?
Minden projektünkben így dolgozunk, legyen szó mobilról, webről vagy AI-ról. Ha olyan csapatot keresel, amelyik így gondolkodik a termékedről, beszéljünk.
Kérj ingyenes becslést