Korniza Appium vs Native: Një krahasim

Nga Kouros Aliabadi dhe Rohan Janjua

Ky postim është një përmbledhje e përvojave tona dhe jo domosdoshmërisht e gjithë fotografia. Ne do t'ju ofrojmë disa lidhje dhe do të ndërtojmë mbi këtë në postimet e ardhshme për t'ju ndihmuar në hulumtimin tuaj. Shpresojmë se kjo do të jetë një pikënisje e mirë për këdo që dëshiron të bëjë zgjedhjen midis disa prej mënyrave kryesore të automatizimit celular.

Ekzistojnë mjete alternative të automatizimit atje, por për kontekstin e këtij postimi në blog, ne do të kufizohemi në këtë Appium dhe mjetet amtare të vendosura për iOS dhe Android: XCUITests dhe Espresso respektivisht.

Appium:

Appium ka qenë mjeti defacto për automatizimin celular në vitet e fundit, duke siguruar një përvojë seleniumi. Deri më tani ajo ka qenë një nga zgjedhjet më të vlefshme profesionalisht për një numër arsyesh.

  1. Së pari është gjuhë agnostike, që vjen me mbështetje për një gamë të gjerë gjuhësh popullore. Nëse gjuha juaj e zgjedhur ka një klient të një webdriver, ju jeni në gjendje të përdorni Appium. Kjo varet nga jsonWireProtocol e përbashkët. Ky është një lehtësi e shkëlqyeshme pasi lejon zhvilluesit e provave të marrin mjetin shpejt. Gjuhët e mbështetura përfshijnë, por nuk kufizohen vetëm në Java, C #, JavaScript, Python dhe Ruby.
  2. Shtë shumë e thjeshtë të vini dhe të filloni me lehtësi. Ngjashëm me pikën e mëparshme, Appium ka shumë ngjashmëri me drejtorin e internetit të Selenit. Dobia e kësaj është se nëse zhvilluesit e testit janë mësuar të shkruajnë teste në internet të drejtuesit të selenit, atëherë Appium duhet të jetë relativisht i thjeshtë për tu kapur dhe mjaft intuitiv.
  3. Appium mundëson testimin e shumë platformave nga e njëjta bazë e provës. Për ata që punojnë në një ekip të centralizuar testimi ose në një ekip që punon në të dy iOS dhe Android, ai mund të zvogëlojë sasinë e kodit boilerplate të kërkuar për të punuar me infrastrukturën e provës dhe emuluesit.
  4. Për më tepër, në përvojën e disa prej inxhinierëve tanë të testimit, mbështetja për aplikacione vendase që përdorin faqet e internetit është më e mirë në Appium sesa shumica e konkurrentëve të tjerë. Mbështetja e ofruar nga Appium mund të jetë e paçmueshme kur bëhet fjalë për automatizimin e aplikacioneve hibride.

Ekzistojnë gjithashtu disa disavantazhe në përdorimin e Appium:

  1. Në përvojën tonë, testet Appium funksionojnë shumë më ngadalë sesa testet e shkruara në XCUITests ose Espresso
  2. Kodi i provës nuk jeton me kodin dev. Tani kjo mund të jetë për diskutim, por ne vendosmërisht mendojmë se kodi i testit dhe kodi dev duhet të jetojnë afër njëri-tjetrit.
  3. Për testimin e aplikacioneve të platformave kryq, gjithmonë do të ketë disa shkallë të kompleksitetit teknik të përfshirë me Appium. Ju ose duhet të:
  4. Mirëmbani 2 grupe PageObjects / ScreenObjects që respektojnë një kontratë të vetme në mënyrë që ato të mund të thirren nga vetëm një grup provash.
  5. Shkruaj 2 grupe provash
  6. Sigurohuni që zhvilluesit të përdorin të njëjtat ID në të dyja aplikacionet

Mjetet amtare:

Dy platformat kryesore për zhvillimin e aplikacioneve tani kanë mjete mjaft konkurruese të UI të tyre: XCUITest dhe Espresso. Pjekuria e këtyre dy mjeteve është përmirësuar në mënyrë dramatike dhe në një bisedë të fundit në WWDC 2017Apple kanë bërë të qartë se ato janë shumë aktive në punën për të përmirësuar mjetet e tyre të automatizimit UI.

  1. Ekziston një avantazh themelor për të përdorur XCUITest dhe Espresso: ato janë krijuar nga ofruesit e platformës: Apple dhe Google. Këto mjete gjithmonë do të jenë përpara kurbës për testimin iOS dhe Android. Featuredo veçori e re nga Appium në të shumtën e rasteve do të ndërtohej mbi funksionimin e një mjeti ekzistues amtare.
  2. Një përfitim tjetër i madh në sytë tanë është se ju do të përfshini kodin e provës me kodin burimor të projektit tuaj. Kjo ndoshta është për diskutim pak, por ne do ta diskutojmë këtë në një postim të ardhshëm. Tani për tani thjesht do të deklarojmë se besojmë se përfshirja e kodit tuaj të testit brenda të njëjtit projekt dhe në të njëjtën gjuhë që përdorin programuesit tuaj ka përfitime të mëdha. Ai jep më shumë nxitje për bashkëpunim brenda ekipit dhe lejon të gjithë të kontribuojnë lehtësisht në këtë aspekt të zhvillimit të softuerit.
  3. Ndonjëherë përvoja android supozohet të jetë e ndryshme nga përvoja iOS, duke shkruar testet tuaja për secilën platformë nuk duhet të komplikoni kornizën tuaj të provave për të trajtuar këto situata.
  4. Shumë më pak flakë. Mjetet amtare thjesht janë më pak të çuditshme. Mund të ketë diçka të bëjë me një numër më të vogël të pjesëve lëvizëse dhe më pak shtresa komunikimi midis kodit të provës dhe instrumentacionit, por testet e shkruara me mjete amtare duket se janë shumë më pak të çuditshme.
  5. Ju mund të përdorni një mjet shumë më të madh se sa nëse përdorni një mjet si Appium. Për shembull me Android ju keni qasje në bibliotekën UiAutomator dhe bibliotekën Espresso.

Espresso:

Vegla e testimit Android në Google Espresso ka disa karakteristika të përsosura që ia vlen të përmenden.

  1. Espresso është shumë e shpejtë, ne kurrë nuk kemi parë diçka kaq të shpejtë në automatizimin UI. Likeshtë si Flash e automatizmit UI, asnjë mjet tjetër nuk i afrohet shpejtësisë.
  2. Ju nuk duhet të shqetësoheni për të pritur që gjërat të ndodhin ose të përfundojnë në kodin tuaj të provës pasi Espresso e trajton këtë për ju, duke përjashtuar disa raste të jashtëzakonshme. Kjo në thelb merr gjënë më të brishtë në lidhje me automatizimin UI jashtë ekuacionit.
  3. Espresso merr një qasje testimi të 'kutisë gri'. Jo mjaft kuti e zezë, jo mjaft e bardhë. Me ekspres testuesi ka një kontroll shumë më të madh mbi aplikimin sesa në një mjet kutie të zezë si appium.
  4. Espresso lejon testuesin të përdorë mjete si Robolectric, një kornizë për ekzekutimin e SDK Android pa filluar një imitues ose kyçje në një pajisje. Farë do të thotë kjo është se testet tuaja fillojnë më shpejt dhe gjithashtu funksionojnë më shpejt.

Ekziston një kornizë e ngjashme me Espresso, krijuar gjithashtu nga Google, për testimin e iOS e cila vlen të përmendet këtu: EarlGrey. Ne nuk e kemi përdorur atë, por nëse sjell disa nga përfitimet e Espresso në iOS, ia vlen të hulumtoheni.

Ekzistojnë gjithashtu disa disavantazhe në përdorimin e mjeteve të provës Native:

  1. Nëse jeni duke zhvilluar një aplikacion të platformës kryq, ju do të duhet të mbani dyfishin e testeve në krahasim me nëse keni përdorur një mjet si Appium.
  2. Nëse jeni duke zhvilluar një aplikacion të platformës kryq, do të duhet të dini dy gjuhë.
  3. Më shumë kompleksitet mund të përfshihen në këtë qasje. Ky është një efekt anësor i fuqisë dhe aksesit shtesë që një mjet si Espresso mund t'i japë testuesit. Për shembull, Espresso automatikisht pret që ngjarjet të përfundojnë në aplikacionin nën test duke përdorur një IdlingResource. Sidoqoftë, për disa raste, testuesi duhet të zbatojë me dorë IdlingResource.
  4. Me një mjet si Espresso, testuesi mund ta vendos aplikacionin në një gjendje që mund të mos jetë në gjendje të arrijë nga këndvështrimi i një përdoruesi. Përsëri, kjo është ana tjetër e fuqisë shtesë që ju merrni.