EarlGrey vs KIF - Тестова рамка

**Опровержение**

Тази публикация говори най-вече за EarlGrey и направи кратко сравнение с KIF.

Преди няколко седмици се запознах с EarlGrey (Да! Може би закъснявам). EarlGrey е тестова рамка за автоматизация на потребителския интерфейс, разработена от Google, текущата му версия е 1.14.0 и е много активна в GitHub в момента.

Earlgrey vs KIF популярност (26.06.2018)

На пръв поглед си помислих, че той може да бъде добър заместител на KIF, защото:

  • Синхронизация: Earlgrey синхронизира мрежова заявка, потребителски интерфейс и нишки. Не е необходимо да чакамеForView или да чакаме повече! Омраза чакане.
  • Проверки на видимостта: Проверява дали елементът е видим, преди да извърши някакво действие.
  • Взаимодействие, подобно на потребителя: Прекарвания и докосвания се извършват с помощта на сензорни събития на ниво приложение.
Взаимодействията на EarlGrey с потребителския интерфейс симулират как реален потребител би взаимодействал с потребителския интерфейс на приложението ви и ви помагат да намерите и поправите същите грешки, които потребителите биха срещнали в приложението ви.

Инсталацията на EarlGrey е проста и може лесно да се извърши чрез cocoapods. Използвахме версията 1.12.1, защото имахме някои проблеми с 1.14.0.

Тестване

Имайки това предвид, решихме да сравним KIF и EarlGrey в реален проект. За целта презаписахме няколко теста с новата рамка. Използваните ни тестове: Xcode 9.3, Quick, Nimble и Nimble-Snapshots.

За да изберете елемент с EarlGrey можем да се обадим:

EarlGrey.select (elementWithMatcher: MATCHER). Изпълнение (ДЕЙСТВИЕ)

Където MATCHER може да бъде всеки GREYMatcher като: accessibilityID, accessibilityLabel, buttonTitle и ACTION всяка GREYAction, напр. кранове, прекарвания, превъртания. За повече информация вижте този мамят лист.

Предимства

Писането на тестове с помощта на EarlGrey е лесно, защото е просто, не е необходимо да чакате почти нищо.

Поради това може да бъде по-лесно за младшите разработчици да започнат да пишат тестове с EarlGrey и поставянето на изчакване на място в кода ви може да бъде опасно.

EarlGrey може да бъде малко по-многословен от KIF, но нищо, с което Wrapper не може да се справи.

проблеми

Първият проблем, който имахме беше, когато използваме accessibilityLabel, някои обаждания в EarlGrey не могат да намерят нашия елемент, но той беше лесно решен чрез добавяне на ID за достъпност към него.

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

Текущи тестове

След като всички тестове са създадени с помощта на KIF и EarlGrey, решихме да стартираме няколко пъти и да проверим времето за изпълнение (в секунди).

Време за изпълнение на тестовия костюм

Таблицата по-горе показва времето в секунди, което EarlGrey и KIF отнемат, за да стартират целия тестов костюм. Можем да забележим, че EarlGrey е със 150% по-бавен, затова решихме да отидем по-дълбоко и да проверим защо.

Записахме времето за изпълнение на всеки тестов клас. Вляво имаме броя на тестовете за всеки клас. Понякога EarlGrey е твърде бавен, но понякога е по-бърз от KIF. Така се объркахме. Какво се случва? Какво правят тестовете твърде бавно?

Сравнение по тестов клас

Затова решихме да отидем по-дълбоко. И проверете какви действия / събития се наричат ​​във всеки тест.

ясни и текстови събитияпрекарайте пръст, докоснете и търсете събития

Можем да забележим, че ясният и въвеждащият текст са по-бързи в EarlGrey, отколкото KIF, но прекарването на пръсти, докосванията и търсенето отнема твърде много време и се запитахме защо?

защо?

Отговорът, който получихме, е от страницата с функции на EarlGrey:

Докосванията и плъзганията се извършват с помощта на събития на допир на ниво приложение, вместо да се използват обработващи събития на ниво елемент. Преди всяко взаимодействие с потребителския интерфейс, EarlGrey твърди, че елементите, с които взаимодействат, са действително видими (вижте Проверки на видимостта), а не само присъстват в йерархията на изгледа. Взаимодействията на EarlGrey с потребителския интерфейс симулират как реален потребител би взаимодействал с потребителския интерфейс на приложението ви и ви помагат да намерите и поправите същите грешки, които потребителите биха срещнали в приложението ви.

докато KIF:

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

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

Опитахме се да го накараме да работи по-бързо, като активирахме бързи анимации

GREYTestHelper.enableFastAnimation ()

Което наистина го кара да работи по-бързо, но не по-бързо от KIF.

EarlGrey x KIF x EarlGrey (Бърза анимация)

Но ние се запитахме дали EarlGrey симулира реален потребител, като позволява бързите анимации все още симулират истински потребител?

заключение

EarlGrey по-лош ли е от KIF? Отговорът е НЕ! Не можете да изхвърлите EarlGrey, само защото е по-бавен. Целта на EarlGrey не е да бъде най-бързата налична рамка за тестове.

И така, кой да използвам? Това зависи дали искате бърз тестов костюм? Или да се възползвате от синхронизация, проверка на видимостта и потребителско взаимодействие?

Ако искате по-бърз костюм, използвайте KIF, ако искате прост, може би EarlGrey е най-доброто обаждане.

Ps: Ако тази публикация ви харесва, споделете я в Twitter, препоръчайте я на среда или и двете =). Това наистина ми помага да достигна до повече хора. Благодаря много.