Appium срещу Native Framework: Сравнение

От Курос Алиабади и Рохан Джанджуа

Тази публикация е обобщение на нашия опит, а не непременно цялата картина. Ние ще предоставим някои връзки и ще надградим това в бъдещите публикации, за да ви помогнем в собствените си изследвания. Надяваме се, че това ще бъде добра отправна точка за всеки, който желае да направи избора между някои от водещите подходи за мобилна автоматизация.

Има алтернативни инструменти за автоматизация, но за контекста на тази публикация в блога ще се ограничим до този Appium и стандартните стандартни инструменти за iOS и Android: XCUITests и Espresso съответно.

Appium:

Appium е defacto инструмент за мобилна автоматизация през последните няколко години, осигуряващ селен подобно преживяване. Досега това беше един от най-професионално изгодните избори поради редица причини.

  1. Първо, това е езиков агностик, идва с поддръжка на широк спектър от популярни езици. Ако вашият език на избор има клиент на уебдиривър, можете да използвате Appium. Това е до споделеното jsonWireProtocol. Това е от голямо удобство, тъй като позволява на разработчиците на тестове бързо да вземат инструмента. Поддържаните езици включват, но не се ограничават до Java, C #, JavaScript, Python и ruby.
  2. Много лесно е да вземете и да започнете лесно. Подобно на предходната точка, Appium има много прилики с уеб седалката Selenium. Предимството на това е, че ако тестовите разработчици са свикнали да пишат уеб тестове на селен webdriver, тогава Appium трябва да бъде сравнително прост за подбор и доста интуитивен.
  3. Appium позволява тестване на множество платформи от една и съща база за тестов код. За работещите в централизиран тестов екип или екип, който работи както в iOS, така и в Android, той може да намали количеството код на кокетната плоча, необходим за работа с тестовата инфраструктура и емулатори.
  4. Освен това в опита на някои от нашите тестови инженери, поддръжката за родните приложения, използващи уеб-изгледи, е по-добра в Appium, отколкото повечето други конкуренти. Подкрепата, предоставена от Appium, може да бъде безценна, когато става въпрос за автоматизиране на хибридни приложения.

Има и някои недостатъци при използването на Appium:

  1. Според нашия опит тестовете на Appium работят много по-бавно от тестовете, написани или в XCUITests или в Espresso
  2. Тестовият код не живее с dev кода. Сега това може да е за дебат, но ние твърдо смятаме, че тестовият код и кодът за разработка трябва да живеят близо един до друг.
  3. За тестване на приложения за крос платформа винаги ще има някаква степен на техническа сложност, свързана с Appium. Или трябва да:
  4. Поддържайте 2 комплекта PageObjects / ScreenObjects, които се придържат към един договор, така че да могат да бъдат извиквани само от един набор от тестове.
  5. Напишете 2 теста
  6. Уверете се, че разработчиците използват един и същ идентификатор в двете приложения

Родни инструменти:

Двете основни платформи за разработка на приложения вече разполагат със собствени много конкурентни инструменти за автоматизация на потребителския интерфейс: XCUITest и Espresso. Зрелостта на тези два инструмента се е подобрила драстично и в неотдавнашна беседа на WWDC 2017Apple стана ясно, че те са много активни в работата по подобряването на своите инструменти за автоматизация на потребителския интерфейс.

  1. Има основно предимство от използването на XCUITest и Espresso: те са създадени от доставчиците на платформата: Apple и Google. Тези инструменти винаги ще изпреварват кривата за тестване на iOS и Android. Всяка нова функция от Appium в повечето случаи ще бъде изградена върху функционалността на съществуващ собствен инструмент.
  2. Друго основно предимство в нашите очи е, че ще включите тестовия код с изходния код на вашия проект. Това може да е леко за дебат, но ние ще обсъдим това в бъдещ пост. Засега просто ще заявим, че вярваме, че включването на вашия тестов код в същия проект и на същия език, който вашите разработчици използват, има големи предимства. Той дава по-голям стимул за сътрудничество в екипа и позволява на всеки лесно да допринесе за този аспект на разработката на софтуер.
  3. Понякога опитът с андроид се предполага, че е различен от преживяването на iOS, като пишете тестовете си за всяка платформа, не е нужно да усложнявате своята тестова рамка, за да се справите с тези ситуации.
  4. Много по-малко люспест. Родните инструменти просто са по-малко люспести. Това може да има нещо общо с по-малък брой движещи се части и по-малко слоеве на комуникация между тестовия код и инструменталното оборудване, но тестовете, написани с нативните инструменти, изглежда са много по-нестабилни.
  5. Можете да използвате много по-голям набор от инструменти, отколкото ако използвате инструмент като Appium. Например с Android имате достъп както до библиотеката UiAutomator, така и до библиотеката на Espresso.

Espresso:

Инструментът на Google за тестване на Android Espresso има свои собствени чисти функции, които си заслужава да бъдат споменати.

  1. Еспресото е много бързо, никога не сме виждали нещо толкова бързо в автоматизацията на потребителския интерфейс. Подобно на автоматизацията Flash of UI, никой друг инструмент не се доближава до скоростта му.
  2. Не е нужно да се притеснявате да чакате нещата да се случат или да завършат в тестовия си код, тъй като Espresso се справя с вас, с изключение на някои изключителни случаи. Това по принцип извежда най-крехкото нещо за автоматизацията на потребителския интерфейс от уравнението.
  3. Espresso използва подход за тестване на "сива кутия". Не съвсем черна кутия, не съвсем бяла. С еспресо тестерът има много повече контрол върху приложението, отколкото в инструмент с черна кутия като appium.
  4. Espresso позволява на тестера да използва инструменти като Robolectric, рамка за стартиране на Android SDK без стартиране на симулатор или включване на устройство. Това означава, че тестовете ви стартират по-бързо и също стартират по-бързо.

Има рамка, подобна на Espresso, също създадена от Google, за тестване на iOS, която заслужава да се спомене тук: EarlGrey. Не сме го използвали, но ако той носи някои от предимствата на Espresso за iOS, си струва да проучите.

Има и някои недостатъци при използването на Native тестови инструменти:

  1. Ако разработвате приложение за крос платформа, потенциално ще трябва да поддържате два пъти повече тестове в сравнение с това, ако сте използвали инструмент като Appium.
  2. Ако разработвате приложение за крос платформа, ще трябва да знаете два езика.
  3. В този подход може да се включи повече сложност. Това е страничен ефект от допълнителната мощност и достъп, който инструмент като Еспресо може да даде на тестера. Например Espresso автоматично чака събитията да приключат в тестваното приложение, използвайки IdlingResource. Въпреки това за някои случаи тестерът ще трябва да внедри IdlingResource ръчно.
  4. С инструмент като Espresso тестерът може да постави приложението в състояние, до което може да не достигне от гледна точка на потребителя. Отново това е другата страна на допълнителната мощност, която получавате.