Appium vs Native Frameworks: Srovnání

Kouros Aliabadi a Rohan Janjua

Tento příspěvek je souhrnem našich zkušeností a ne nutně celého obrazu. Budeme poskytovat některé odkazy a stavět na tom v budoucích příspěvcích, které vám pomohou ve vašem vlastním výzkumu. Doufáme, že to bude dobrým výchozím bodem pro každého, kdo si chce vybrat mezi některými z předních přístupů k automatizaci mobilních zařízení.

Existují alternativní nástroje pro automatizaci, ale v souvislosti s tímto příspěvkem na blogu se omezíme na toto Appium a výchozí nativní nástroje pro iOS a Android: XCUITests a Espresso.

Appium:

Appium je v posledních několika letech nástrojem pro mobilní automatizaci, který poskytuje zážitek podobný selenu. Doposud to byl jeden z nejvíce profesionálně životaschopných výběrů z mnoha důvodů.

  1. Zaprvé je to jazyková agnostika, přichází s podporou široké škály populárních jazyků. Pokud má váš jazyk výběru klienta webového ovladače, můžete použít Appium. Jedná se o sdílený soubor jsonWireProtocol. To je velmi výhodné, protože umožňuje vývojářům testů rychle vyzvednout nástroj. Mezi podporované jazyky patří mimo jiné Java, C #, JavaScript, Python a rubín.
  2. Je velmi snadné vyzvednout a snadno začít. Podobně jako v předchozím bodě má Appium spoustu podobností s webovým ovladačem Selenium. Výhodou je to, že pokud jsou vývojáři testů zvyklí psát webové testy selenového webového ovladače, mělo by být Appium relativně snadné vyzvednout a docela intuitivní.
  3. Appium umožňuje testování více platforem ze stejné základny testovacího kódu. Pro ty, kteří pracují v centralizovaném zkušebním týmu nebo týmu, který pracuje napříč iOS i Androidem, může snížit množství kódu kotlové desky potřebné pro práci s testovací infrastrukturou a emulátory.
  4. Kromě zkušeností některých našich zkušebních techniků je podpora nativních aplikací využívajících webové pohledy na Appiu lepší než většina ostatních konkurentů. Podpora poskytované Appiem může být neocenitelná, pokud jde o automatizaci hybridních aplikací.

Použití Appia má také některé nevýhody:

  1. Podle našich zkušeností běží testy Appium mnohem pomaleji než testy napsané v XCUITests nebo Espresso
  2. Zkušební kód nežije s kódem dev. Teď to může být pro debatu, ale pevně cítíme, že testovací kód a dev kód by měly žít blízko u sebe.
  3. Pro testování aplikací napříč platformami bude s aplikací Appium vždy existovat určitý stupeň technické složitosti. Buď musíte:
  4. Udržujte 2 sady PageObjects / ScreenObjects, které dodržují jednu smlouvu, takže je lze volat pouze z jedné sady testů.
  5. Napište 2 sady testů
  6. Zajistěte, aby vývojáři používali stejné ID v obou aplikacích

Nativní nástroje:

Dvě hlavní platformy pro vývoj aplikací mají nyní velmi konkurenční nástroje pro automatizaci uživatelského rozhraní: XCUITest a Espresso. Zralost těchto dvou nástrojů se dramaticky zlepšila a v nedávné přednášce na WWDC 2017Apple daly najevo, že jsou velmi aktivní při zlepšování svých automatizačních nástrojů uživatelského rozhraní.

  1. Používání XCUITest a Espresso má zásadní výhodu: jsou vytvářeny poskytovateli platformy: Apple a Google. Tyto nástroje budou vždy před křivkou pro testování na iOS a Android. Jakákoli nová funkce z Appium by ve většině případů byla postavena na vrcholu stávajících funkcí nativního nástroje.
  2. Další velkou výhodou v našich očích je, že do zdrojového kódu vašeho projektu zahrnete testovací kód. Tohle je možná trochu pro rozpravu, ale budeme o tom diskutovat v budoucím příspěvku. Prozatím prohlásíme, že věříme, že zahrnutí vašeho testovacího kódu do stejného projektu a ve stejném jazyce, jaký používají vaši vývojáři, má velké výhody. Poskytuje větší motivaci ke spolupráci v týmu a umožňuje každému snadno přispívat k tomuto aspektu vývoje softwaru.
  3. Někdy se má zkušenost se systémem Android lišit od zkušeností se systémem iOS tím, že píšete své testy pro každou platformu, abyste nemuseli komplikovat svůj testovací rámec, aby zvládli tyto situace.
  4. Mnohem méně šupinatá. Nativní nástroje jsou prostě méně šupinaté. Může to mít něco společného s menším počtem pohyblivých částí a menšími vrstvami komunikace mezi testovacím kódem a instrumentací, ale testy psané s nativními nástroji se zdají být mnohem méně šupinaté.
  5. Můžete použít mnohem větší sadu nástrojů, než kdybyste použili nástroj jako Appium. Například v systému Android máte přístup jak do knihovny UiAutomator, tak do knihovny Espresso.

Espresso:

Google testovací nástroj pro Android Espresso má několik úhledných funkcí, které stojí za zmínku.

  1. Espresso je velmi rychlé, v automatizaci uživatelského rozhraní jsme nikdy neviděli něco tak rychlého. Je to jako automatizace Flash of UI, žádný jiný nástroj se nepřibližuje rychlosti.
  2. Nemusíte si dělat starosti s čekáním, až se něco stane nebo skončit v testovacím kódu, protože Espresso to za vás zvládne, vyjma některých výjimečných případů. To v podstatě bere nejkřehčí věc o automatizaci uživatelského rozhraní z rovnice.
  3. Espresso používá testovací přístup „šedého pole“. Ne úplně černá skříňka, ne úplně bílá. S espressem má tester mnohem větší kontrolu nad aplikací než v nástroji černé skříňky, jako je appium.
  4. Espresso umožňuje testerovi využívat nástroje jako Robolectric, rámec pro provoz Android SDK bez spuštění simulátoru nebo připojení zařízení. To znamená, že vaše testy začínají rychleji a také rychleji.

Existuje rámec podobný Espressu, vytvořený také společností Google, pro testování na iOS, který stojí za zmínku zde: EarlGrey. Nevyužili jsme to, ale pokud přináší iOS Espresso některé z výhod, stojí za to prozkoumat.

Existují také některé nevýhody používání nativních testovacích nástrojů:

  1. Pokud vyvíjíte aplikaci pro více platforem, budete pravděpodobně muset udržovat dvojnásobný počet testů ve srovnání s tím, pokud jste použili nástroj jako Appium.
  2. Pokud vyvíjíte aplikaci pro více platforem, musíte znát dva jazyky.
  3. Do tohoto přístupu může být zapojena větší složitost. To je vedlejší účinek zvýšené síly a přístupu, který může nástroj jako Espresso dát testerovi. Například Espresso automaticky čeká na dokončení událostí v testované aplikaci pomocí IdlingResource. V některých případech však bude muset tester implementovat IdlingResource ručně.
  4. S nástrojem, jako je Espresso, může tester uvést aplikaci do stavu, který nemusí být schopen dosáhnout z pohledu uživatele. Opět je to druhá strana další síly, kterou získáte.