Appium vs Native Framework: Primerjava

Avtorja Kouros Aliabadi in Rohan Janjua

Ta objava je povzetek naših izkušenj in ne nujno celotna slika. Navedli bomo nekaj povezav in nadgradili to v prihodnjih objavah, da vam bomo pomagali pri lastnih raziskavah. Upamo, da bo to dobro izhodišče za vse, ki se želijo odločiti za nekatere izmed vodilnih pristopov za mobilno avtomatizacijo.

Na voljo so drugačna orodja za avtomatizacijo, vendar se bomo v okviru te objave na spletnem dnevniku omejili na ta Appium in privzeta izvorna orodja za iOS in Android: XCUITests in Espresso.

Appium:

Appium je bilo v zadnjih nekaj letih orodje za razvoj mobilne avtomatizacije, ki je podobno selenu. Do zdaj je bila to ena izmed najbolj strokovno izvedljivih odločitev zaradi številnih razlogov.

  1. Prvič, to je jezikovni agnostik, ki nudi podporo širokemu krogu priljubljenih jezikov. Če ima vaš izbrani jezik odjemalec spletnih ponudnikov, lahko uporabljate Appium. To je omejeno na skupno rabo jsonWireProtocol. To je v veliko korist, saj razvijalcem preizkusov omogoča, da orodje hitro poberejo. Podprti jeziki vključujejo Java, C #, JavaScript, Python in ruby, vendar niso omejeni nanje.
  2. Zelo enostavno je, da se zberete in začnete z lahkoto. Podobno kot prejšnja točka ima tudi Appium veliko podobnosti s spletnim gonilnikom Selenium. Prednost tega je, da če so razvijalci testov navajeni pisati spletne teste selelena webdriver, bi moral biti Appium razmeroma enostaven za izbiro in dokaj intuitiven.
  3. Appium omogoča testiranje več platform iz iste baze preskusne kode. Za tiste, ki delajo v centralizirani testni skupini ali ekipi, ki deluje tako v operacijskem sistemu iOS kot Android, lahko zmanjšate količino kode plošče, potrebno za delo s testno infrastrukturo in emulatorji.
  4. Poleg izkušenj nekaterih naših testnih inženirjev je podpora domačim aplikacijam, ki uporabljajo spletne oglede, na Appiumu boljša od večine drugih konkurentov. Podpora, ki jo ponuja Appium, je lahko neprecenljiva, ko gre za avtomatizacijo hibridnih aplikacij.

Pri uporabi Appiuma obstajajo tudi nekatere pomanjkljivosti:

  1. Po naših izkušnjah Appium testi potekajo precej počasneje kot testi, zapisani bodisi v XCUITests bodisi v Espresso
  2. Testna koda ne deluje s kodo za razvoj. Zdaj je to mogoče za razpravo, vendar trdno menimo, da morata testna koda in koda za razvijanje živeti drug drugemu.
  3. Za testiranje aplikacij za več platform bo z Appiumom vedno na voljo nekaj tehnične zahtevnosti. Morate:
  4. Vzdržujte 2 sklopa PageObjects / ScreenObjects, ki se držijo ene pogodbe, tako da jih lahko pokličete samo iz enega niza preskusov.
  5. Napiši 2 sklopa testov
  6. Zagotovite, da razvijalci uporabljajo enak ID v obeh aplikacijah

Native orodja:

Dve glavni platformi za razvoj aplikacij imata zdaj zelo konkurenčna orodja za avtomatizacijo uporabniškega vmesnika: XCUITest in Espresso. Zrelost teh dveh orodij se je dramatično izboljšala in v nedavnem pogovoru na WWDC 2017Apple sta jasno povedala, da sta zelo dejavna pri izboljšanju svojih orodij za avtomatizacijo uporabniškega vmesnika.

  1. Uporaba XCUITest in Espresso je temeljna prednost: ustvarili sta jih ponudniki platform: Apple in Google. Ta orodja bodo vedno pred krivuljo za testiranje iOS in Android. Vsaka nova funkcija Appiuma bi bila v večini primerov zgrajena na podlagi obstoječega funkcij domačega orodja.
  2. Druga velika prednost v naših očeh je, da boste vključili preskusno kodo z izvorno kodo svojega projekta. To bo morda nekoliko razprava, vendar bomo o tem razpravljali v prihodnjem postu. Zaenkrat bomo navedli samo, da verjamemo, da ima tudi vaša testna koda v istem projektu in v istem jeziku, ki ga uporabljajo vaši razvijalci, velike koristi. Daje več spodbude za sodelovanje znotraj ekipe in vsem omogoča, da zlahka prispevajo k temu vidiku razvoja programske opreme.
  3. Včasih naj bi bila izkušnja z androidom drugačna kot pri iOS-u, saj s pisanjem testov za vsako platformo ni treba zapletati svojega testnega okvira za obvladovanje teh situacij.
  4. Veliko manj luskav. Native orodja so le manj kosmati. Morda ima nekaj opravka z manjšim številom premikajočih se delov in manj slojev komunikacije med preskusno kodo in instrumentacijo, toda testi, napisani z izvornimi orodji, so videti precej manj lahki.
  5. Uporabite lahko veliko večje nabor orodij, kot če uporabljate orodje, kot je Appium. Na primer s sistemom Android imate dostop do knjižnice UiAutomator in knjižnice Espresso.

Espresso:

Googlovo orodje za testiranje Android Espresso ima nekaj lastnih čednih lastnosti, ki jih je vredno omeniti.

  1. Espresso je zelo hiter, v avtomatizaciji uporabniškega vmesnika še nikoli nismo videli kaj tako hitrega. Tako je kot avtomatizacija Flash of UI, nobeno drugo orodje se ne približa hitrosti.
  2. Ni vam treba skrbeti, da čakate, da se bodo stvari zgodile ali končale v testni kodi, ko Espresso to obravnava, razen nekaterih izjemnih primerov. V bistvu to najbolj enakomerno zadeva avtomatizacijo uporabniškega vmesnika iz enačbe.
  3. Espresso je pristop k testiranju "sive škatle". Ne čisto črna skrinjica, ne čisto bela. Pri espressu ima preizkuševalec veliko več nadzora nad aplikacijo kot v orodju črne škatle, kot je appium.
  4. Espresso omogoča preizkuševalcu, da uporablja orodja, kot je Robolectric, okvir za zagon sistema Android SDK, ne da bi zagnali simulator ali vklopili napravo. To pomeni, da se vaši testi začnejo hitreje in tudi teči hitreje.

Obstaja okvir, podoben Espressu, ki ga je ustvaril tudi Google, za testiranje iOS, ki ga je tukaj treba omeniti: EarlGrey. Nismo je še uporabljali, toda če prinaša nekatere prednosti Espressa za iOS, je vredno raziskati.

Pri uporabi orodij za testiranje Native je tudi nekaj slabosti:

  1. Če razvijate aplikacijo za več platform, boste morda morali ohraniti dvakrat več preskusov v primerjavi z orodjem, kot je Appium.
  2. Če razvijate aplikacijo za več platform, boste morali znati dva jezika.
  3. Pri tem pristopu je mogoče vključiti več kompleksnosti. To je stranski učinek dodatne moči in dostopa, ki ga lahko orodje, kot je Espresso, nudi preizkuševalcu. Na primer, Espresso samodejno čaka, da se dogodki v preizkusni aplikaciji zaključijo z uporabo IdlingResource. Vendar bo moral v določenih primerih preizkuševalnik IdlingResource izvajati ročno.
  4. Z orodjem, kot je Espresso, lahko preizkuševalec aplikacijo postavi v stanje, ki ga z vidika uporabnika morda ne bo mogel doseči. Spet je to druga stran dodatne moči, ki jo dobite.