Aatrium vs loodusraamid: võrdlus

Autorid Kouros Aliabadi ja Rohan Janjua

See postitus on kokkuvõte meie kogemustest ja mitte tingimata kogu pilt. Pakume mõned lingid ja tugineme sellele tulevastes postitustes, et aidata teil oma teadusuuringuid. Loodame, et see on heaks lähtepunktiks kõigile, kes soovivad valida mõne juhtiva mobiilse automatiseerimise lähenemisviisi vahel.

Seal on küll alternatiivseid automatiseerimisriistu, kuid selle ajaveebi postituse kontekstis piirdume selle Appiumi ja iOS-i ja Androidi vaiketüüpi tööriistadega: vastavalt XCUITests ja Espresso.

Aatrium:

Appium on viimastel aastatel olnud defacto tööriist mobiilse automatiseerimise jaoks, pakkudes seleenilaadset kogemust. Siiani on see olnud mitmel põhjusel üks professionaalselt kõige otstarbekamaid valikuid.

  1. Esiteks on see keeleagnostika, mis pakub tuge paljudele populaarsetele keeltele. Kui teie valitud keeles on veebidriveri klient, saate kasutada Appiumit. See jääb jagatud jsonWireProtocol juurde. See on väga mugav, kuna see võimaldab testide arendajatel tööriista kiiresti kätte saada. Toetatud keelte hulka kuuluvad, kuid mitte ainult, Java, C #, JavaScript, Python ja ruby.
  2. Selle vastuvõtmine ja alustamine on väga lihtne. Sarnaselt eelmisele punktile on ka Appiumil palju sarnasusi Seleeni veebidriveriga. Selle eeliseks on see, et kui testi arendajad on harjunud seleeni veebidriveri veebiteste kirjutama, peaks Appium olema ülesvõtmiseks suhteliselt lihtne ja üsna intuitiivne.
  3. Appium võimaldab testida mitut platvormi samast testkoodialusest. Neile, kes töötavad tsentraliseeritud testimisrühmas või meeskonnas, mis töötab nii iOS-is kui ka Androidis, saab see vähendada testiinfrastruktuuri ja emulaatoritega töötamiseks vajalikku katlakoodi koodi.
  4. Lisaks on mõnede meie testiinseneride kogemuste põhjal Appiumil parem veebiülevaateid kasutavate loodusrakenduste tugi kui enamikul teistel konkurentidel. Appiumi pakutav tugi võib hübriidrakenduste automatiseerimisel olla hindamatu väärtus.

Appiumi kasutamisel on ka mõned puudused:

  1. Meie kogemuste kohaselt kulgevad Appiumi testid palju aeglasemalt kui testid, mis on kirjutatud kas XCUITestides või Espressos
  2. Testkood ei koostu dev-koodist. Nüüd võib see aruteluks olla, kuid usume kindlalt, et testikood ja dev-kood peaksid elama üksteise lähedal.
  3. Platvormidevaheliste rakenduste testimiseks on Appiumiga alati seotud teatav tehniline keerukus. Peate kas:
  4. Hooldage 2 PageObjektide / ScreenObjektide komplekti, mis vastavad ühele lepingule, nii et neid saab kutsuda ainult ühest testikomplektist.
  5. Kirjutage 2 testi komplekti
  6. Veenduge, et arendajad kasutaksid mõlemas rakenduses sama ID-d

Natiivsed tööriistad:

Kahel peamisel rakenduste arendamise platvormil on nüüd omaenda väga konkurentsivõimelised kasutajaliidese automatiseerimise tööriistad: XCUITest ja Espresso. Nende kahe tööriista küpsus on dramaatiliselt paranenud ja hiljutises WWDC 2017Apple'i vestluses on selgeks tehtud, et nad töötavad UI automatiseerimisriistade täiustamisel väga aktiivselt.

  1. XCUITesti ja Espresso kasutamisel on põhimõtteline eelis: need loovad platvormi pakkujad: Apple ja Google. Need tööriistad on alati iOS-i ja Androidi testimise kõvera ees. Kõik Appiumi uued funktsioonid rajatakse enamasti olemasoleva loomuliku tööriista funktsionaalsuse peale.
  2. Teine suur eelis meie silmis on see, et lisate testkoodi oma projekti lähtekoodiga. Võib-olla on see pisut arutamiseks, kuid arutame seda tulevases postituses. Praegu ütleme lihtsalt, et usume, et teie testkoodi kaasamisega samasse projekti ja samas keeles, mida teie arendajad kasutavad, on palju eeliseid. See annab rohkem stiimu meeskonnasiseseks koostööks ja võimaldab kõigil hõlpsalt kaasa aidata selle tarkvaraarendamise aspektile.
  3. Mõnikord peaks androidi kogemus erinema iOS-i kogemusest, kirjutades iga platvormi jaoks testid, te ei pea nende olukordade lahendamiseks oma testraamistikku keerukamaks tegema.
  4. Palju vähem helbed. Looduslikud tööriistad on lihtsalt vähem helbed. Võimalik, et sellel on pistmist väiksema arvu liikuvate osadega ning testkoodi ja mõõteriistade vahelise väiksema suhtluskihiga, kuid looduslike tööriistadega kirjutatud testid tunduvad olevat palju vähem kihutavad.
  5. Võite kasutada palju suuremat tööriistakomplekti kui siis, kui kasutate sellist tööriista nagu Appium. Näiteks Androidi puhul on teil juurdepääs nii UiAutomatori raamatukogule kui ka Espresso raamatukogule.

Espresso:

Google'i Androidi testimisriistul Espressol on mõned omapärased omadused, mida tasub mainida.

  1. Espresso on väga kiire, me pole kunagi kasutajaliidese automatiseerimisel midagi nii kiiret näinud. See on nagu kasutajaliidese automatiseerimise välklamp, ükski teine ​​tööriist ei lähe selle kiirusele lähedale.
  2. Te ei pea muretsema, kuni asjad juhtuvad või testkood lõpeb, kuna Espresso vastutab teie eest, välja arvatud mõned erandjuhud. Põhimõtteliselt eemaldab võrrandist UI automatiseerimise kõige rabedam asi.
  3. Espresso kasutab nn halli kasti testimismeetodit. Mitte päris must kast, mitte päris valge. Espresso puhul on testeril rakenduse üle palju suurem kontroll kui musta kasti tööriistaga, nagu näiteks appium.
  4. Espresso võimaldab testijal kasutada selliseid tööriistu nagu Robolectric, mis on raamistik Androidi SDK käitamiseks ilma simulaatorit käivitamata või seadet ühendamata. See tähendab, et teie testid käivituvad kiiremini ja käivad ka kiiremini.

IOS-i testimiseks on olemas ka Google'i loodud Espressoga sarnane raamistik, mida tasub siin mainida: EarlGrey. Me pole seda kasutanud, kuid kui see toob iOS-ile mõned Espresso eelised, siis tasub seda uurida.

Native testimisriistade kasutamisel on ka mõned puudused:

  1. Platvormideülese rakenduse arendamisel peate potentsiaalselt ületama testide arvu kaks korda rohkem kui siis, kui kasutasite sellist tööriista nagu Appium.
  2. Platvormideülese rakenduse arendamisel peate teadma kahte keelt.
  3. Selle lähenemisviisiga võib kaasneda keerulisem. See on lisajõu ja juurdepääsu kõrvalmõju, mille selline tööriist nagu Espresso võib testijale anda. Näiteks Espresso ootab IdlingResource abil testitavas rakenduses sündmuste lõppemist. Mõnel juhul peab testija IdlingResource'i käsitsi rakendama.
  4. Espresso-taolise tööriista abil saab testija viia rakenduse olekusse, kuhu see kasutaja vaatevinklist ei pruugi jõuda. See on jällegi teie saadaoleva lisajõu teine ​​külg.