Xamarin.UITest is a C# test automation framework that enables testing mobile apps on Android and iOS. Mobile automation is not a piece of cake but Xamarin.UITest aims to provide a suitable abstraction on top of the platform tools to let you focus on what to test. This talk is not only an introduction of framework but also we are going to present its practical aspects, technical details, benefits and disadvantages. We will show a growing process from “Zero” – when you have only few local tests, to “Hero” – when you run your tests simultaneously and have fully integrated solution into CI/CD pipeline.
12. ▪ Tap
▪ Scroll
▪ Swipe
▪ Pinch
▪ EnterText
▪ ClearText
▪ Back
▪ Query
▪ WaitFor(No)Element
Commands
13. Queries ▪ Id
▪ Class
▪ Text
▪ Button
▪ Property
▪ Marked
▪ XPath
▪ Css
▪ Child
▪ etc.
14. Input element on the screen:
[AppCompatEditText]id:"userName"
Queries
Usage example
Can be defined as:
- app.Query("userName");
- app.Query(x=>x.Id("userName"));
- app.Query(x=>x.TextField("userName"));
- app.Query(x=>x.Marked("userName"));
- app.Query(x=>x.Class("AppCompatEditText")
.Index(0));
21. BONUS!
Backdoors
Changes in the source code of mobile app
[Export("TodoBackdoor")]
public void TodoBackdoor()
{
Intent i = new Intent(this, typeof(TodoActivity));
StartActivity(i);
}
Using this method in the test
App.Invoke("TodoBackdoor");
Deep Linking
31. Disadvantages
● Xamarin.iOS app requires a special build
(without a source code automation is not
possible);
● Difference in platform capabilities;
● Application may not respond;
● Doesn’t support some hardware features;
● No integration with other apps installed on the
device;
32. SUMMARY ● Choose a test automation tool based on the
development software;
● Xamarin.UITest is easy to use;
● Don’t think about platform specifics, write tests;
● One test - two platforms, it works;
● Run your mobile tests in parallel using your own
device farm or test cloud;
● CI/CD integration - a must-have for a mobile
project;
● Work with your developers - teamwork forever;
Сьогодні ми хочемо поділитись з вами досвідом у сфері автоматизованого тестування мобільних додатків за допомогою Xamarin.UITest. Наша тема - перш за все, це приклад спільної роботи qa і девелопера, плюс - історія розвитку проекту “From ZERO - від моменту коли був написаний перший тест... “to HERO” - коли тестами покритий проект, це інтегровано в СІ і тести можуть працювати паралельно.
Тестування мобільних додатків особливе тим що це повинно бути тестування в русі. (опис)...Попри все це практично на кожному проекті рано чи пізно піднімається питання автоматизації. Адже є бізнес логіка яка повинна працювати за будь яких умов. Саме тому доцільно почати писати автоматизовані тести
Чому Xamarin.UITest? Якщо розглядати тестові фреймворки, він не належить до топових. В нашому випадку ми обрали його, оскільки мобільна аплікація була створена на Xamarin і для створення тестового проекту достатньо було додати Xamarin.UITest проект до солюшина. Відповідно не потрібно було заново встановлювати бібліотеки і робити додаткові налаштування. Також одразу зрозуміло що мова написання тестів та ж що і аплікації - С#. Бонусом було те, що над розробкою мобільної аплікації працювала команда, в якої можна було отримати відповідь на будь-яке питання.
In Android, The Xamarin Test Cloud Agent is responsible for using the Android automation APIs to control the user interface and to locate views so that a test may interact with them. It is bundled into a separate APK and runs as a separate application, which has permission to automate the application under test. This is possible, because when the test is deployed to the mobile device, Calabash or UITest will sign both application packages with the same key.
The Test Cloud Agent has a slightly different role in iOS applications – by itself it does not automate the app under test. Instead, the Test Cloud Agent will interrogate the active window and retrieve information about the views for to the user. The view information is returned to the test script. The test script will then automate the iOS application with the help of another component called the DeviceAgent. The DeviceAgent will simulate the gestures and actions for the test (using the automation API's provide with Xcode 8) and if necessary return the result of those interactions to the test
А тепер перейдемо до практичної частини. З чого починати? Перш за все потрібне середовище. Отож ідемо на офіціний сайт visual studio, в залежності від ОС вибираємо Visual Studio чи Visual Studio for Mac. Підходить безкоштовна community версія. Скачуємо, вибираємо пакет встановлення для мобільної розробки, - Xamarin і встановлюємо.
Також нам потрібний тест енджін, в даному випадку це nunit.
Для віндовс в окремих випадках потрібно - Android sdk та Java Developers Kit, для Мак- Xcode Command Line Tools.
Невеличке зауваження, На віндовс можна працювати тільки з Андроїд аплікаціями, на Mac - ios, android.
Припустимо вже все встановлено, настроєно. В туторіалі пропонують взяти готовий зразок з git-hub, де вже є базова сторінка і базовий тест, і спробувати це для своєї аплікації. Або можна створити власний новий проект для кросплатформенного тестування.
В моєму випадку, я створила власний і щоб зрозуміти специфіку поведінки мобільної аплікації -спробувала Xamarin Test Recorder. Я знаю як ставляться автоматизатори до рекордерів, але… перш за все - це мобільна аплікація і якщо у вас немає доступу до вихідного коду, важко зрозуміти з чим ви маєте справу, що ховається за кожним скріном.
Xamarin Test Recorder потрібно окремо встановити - для віндовс це плагін і він доступний тільки для ентерпрайз версії, для VS for mac - це окремий додаток. Принцип роботи приблизно один і той же на обидвох платформах - потрібно підключити девайс, чи переконатись чи є емулятор на якому буде запускатись тестю
Після запуску на віндовс - слід просто вибрати апк вайл, для Mac - девайс і апк чи апп файл і виконати послідовність дій які мають бути в тесті.
В результаті створюється готовий тест з комадами які були виконані, є можливість побачити які елементи і які команди використовувались.
Про команди. В принципі, тут є те чим ми з вами користуємся кожного дня, ми тапаємо,скролимо, свайпаємо, працюємо з текстом і ще є досить багато функцій які можна використати як наприклад поворот екрана чи очікування появи чи зникннення елемента на скріні. Невеличкий приклад команд.
Оскільки команди виконуються над елементами, доцільно розглянути селектори. Ідеально коли у процесі розробки було створено AutomationId і тоді не піднімається питання як знайти елемент на скріні. Але ми живемо не в ідеальному світі :)
І ось приклад того як можна один і той же елемент сторінки визначити різними способами.
Тепер про конфігурацію. Впевнена всі знають що основна умова початку тестування - це наявність продукту який має тестуватись. Тобто потрібно вказати артефакт з яким працюватимуть тести.
В даному випадку арефакт - це апк чи апп файл. І базовою конфігурацією є тільки вказаний шлях до файлу аплікації, - апк чи апп.
Крім цього є багато додаткових конфігураційних команд, кожну з яких ви будете використовувати по мірі необхідності.
Але.. Ми ж не будемо використовувати рекордер при розробки.Це забирає час і не завжди точні результати. Рекордер тільки для ознайомлення.
Є ще одна річ, яку безпосередньо прийдеться використовувати - REPL.
Взагалі REPL (Read-eval-print loop — це просте інтерактивне середовище програмування.В такому середовищі користувач може вводити вирази, які середовище одразу обчислить, а результат обчислень відобразить користувачеві.
В плані Xamarin.UITest - це середовище де можна переглядати елементи, працювати з ними, виконувати команди. Для того щоб викликати REPL, потрібно вказати команду в тесті.
Як вже було згадано Xamarin використовується для розробки кросплатформенних аплікації. Відовідно тести також повинні працювати як для iOS так і для Android одинаково, тобто один тест має працювати для обидвох платформ.
Для вирішення цієї проблеми ми створюємо окремі пейдж-обджекти для iOS i Android а потім в залежності від платорми ініціалізуємо їх.
Якщо говорити про самі тести, рекомендується використовувати Arrange-Act-Assert pattern. В даному прикладі ви не зможете побачити “Arrange” оскільки ініціалізація і старт аплікації винесено в сетап функцію. Потім виконується послідовність дій і в кінці йде перевірка чи отримано очікуваний результат.
Пройшовши всі етапи про які я говорила, створивши кілька тестів і організувавши їхню структуру, звичайно, не без допомоги девелопера - з проекту розміром 2 файли, у мене вийшов досить структурований, гнучкий і як на мене інтуїтивно організований проект.
Тепер буде невеличкий “ліричний” відступ. Бекдори. Є люди які знають що це? А діп-лінкінг?
Здавалося б який тут може бути зв’язок.
Deep Linking - це можливість відкрити конкретну сторінку використавши спеціальне посилання. Це широко використовується в рекламі - ви бачите невеличкий банер, клікаєте на нього і відкриваєте окрему сторінку. Це працює і для мобільних аплікацій, ви клікаєте на посилання і якщо у вас є аплікація, відкривається спеціальний скрін, якщо ні, йде редірект на стор.
Бекдор - це спеціальна функція, яка повинна відкривати спеціальний скрін і вона додається в код мобільної аплікації.
Для виклику бекдора в тесті, ми використовуємо Invoke метод.
В цілому це означає що ми маємо можливість відкрити потрібний нам скрін не починаючи з стартового скріна аплікації.
Чому я говорила про “Deep linking” - для використання бекдорів аплікація повинна працювати так, щоб окремий скрін міг працювати не залежно від інших, в іншому випадку це не працює.
І само собою, аплікацію з бекдорами релізити не можна.