This package is a library designed to simplify automation of Android and iOS mobile applications using Appium.
You've got to use this set of methods, related to most common actions performed with web elements.
Most of performed methods are logged using NLog, so you can easily see a history of performed actions in your log.
We use interfaces where is possible, so you can implement your own version of target interface with no need to rewrite other classes.
To start the project using Aquality.Appium.Mobile framework, you can download our template BDD project by this link.
Alternatively, you can follow the steps below:
-
Add the nuget dependency Aquality.Appium.Mobile to your project.
-
Configure path to your application at settings.json:
- Create a
Resources
folder in your project and copy settings.json into it. - Select
Copy to Output Directory
:Copy always
option at settings.json file properties. - Open settings.json and find
applicationPath
option under thedriverSettings
section of desired platform. Replace the value with full or relative path to your app, e.g../Resources/Apps/ApiDemos-debug.apk
.
- Ensure that Appium server is set up at your machine where the code would be executed, and the address/port match to set in your
settings.json
inremoteConnectionUrl
parameter. If the parameterisRemote
in your settings.json is set tofalse
, this means that AppiumDriverLocalService would be used to setup Appium server using Node.js. This option requires specific version of node.js to be preinstalled on your machine (Please read more here )
Note: After migration to Appium v.5, we started using Appium server v.2 in our azure-pipelines. It has some breaking changes, described here. In particular:
- Please install required driver manually:
npm install -g appium@next appium driver install uiautomator2 2. As soon as we continue to use "remoteConnectionUrl": "http://127.0.0.1:4723/wd/hub" in our [settings.json](Aquality.Appium.Mobile/src/Aquality.Appium.Mobile/Resources/settings.json), we need to specify the `--base-path` when starting Appium server: ```yaml appium --allow-insecure chromedriver_autodownload --base-path /wd/hub &
- We also recommend disabling element caching and w3c in chromeOptions when you run Android Chrome session. Take a look at example here: settings.androidwebsession.json.
- (optional) Launch an application directly by calling
var application = AqualityServices.Application;
.
Note: If you don't start an Application directly, it would be started with the first call of any Aquality service or class requiring interacting with the Application.
-
That's it! Now you are able work with Application via AqualityServices or via element services. Please take a look at our example tests here
-
To interact with Application's forms and elements, we recommend following the Page/Screen Objects pattern. This approach is fully integrated into our package. To start with that, you will need to create a separate class for each window/form of your application, and inherit this class from the Screen.
We recommend to use separate Screen class for each form of your application. You can take advantage of inheritance and composition pattern. We also suggest not to mix app different platforms in single class: take advantage of interfaces instead, adding the default implementation to them if is needed.
- From the Screen Object perspective, each Screen consists of elements on it (e.g. Buttons, TextBox, Labels and so on).
To interact with elements, on your form class create fields of type IButton, ITextBox, ILabel, and initialize them using the
AqualityServices.ElementFactory
. Created elements have a various methods to interact with them. We recommend combining actions into a business-level methods:
using Aquality.Appium.Mobile.Elements.Interfaces;
using Aquality.Appium.Mobile.Screens;
using OpenQA.Selenium;
namespace Aquality.Appium.Mobile.Tests.Samples.Android.ApiDemosScreens
{
public class InvokeSearchScreen : AndroidScreen
{
private readonly ITextBox searchTextBox;
private readonly IButton startSearchButton;
private readonly ILabel searchResultLabel;
public InvokeSearchScreen() : base(By.XPath("//android.widget.TextView[@text='App/Search/Invoke Search']"), "Invoke Search")
{
searchTextBox = ElementFactory.GetTextBox(By.Id("txt_query_prefill"), "Search");
startSearchButton = ElementFactory.GetButton(By.Id("btn_start_search"), "Start search");
searchResultLabel = ElementFactory.GetLabel(By.Id("android:id/search_src_text"), "Search results");
}
public void SubmitSearch(string query)
{
searchTextBox.ClearAndType(query);
startSearchButton.Click();
}
public string SearchResult => searchResultLabel.Text;
}
}
- We use
Microsoft.Extensions.DependencyInjection
inside theAqualityServices
to inject dependencies, so you can simply implement your MobileStartup extended from MobileStartup and inject it toAqualityServices.SetStartup(yourStartup)
.
When you automate tests for both iOS and Android platforms it is good to have only one set of tests and different implementations of screens. ScreenFactory
allows to do this. You can define abstract classes for your screens and have different implementations for iOS and Android platforms. After that you can use ScreenFactory
to resolve a necessary screen depending on the chosen platform.
-
Set
screensLocation
property insettings.json
. It is a name of Assembly where you define screens. -
Define abstract classes for the screens:
using Aquality.Appium.Mobile.Elements.Interfaces;
using Aquality.Appium.Mobile.Screens;
using OpenQA.Selenium;
namespace Aquality.Appium.Mobile.Template.Screens.Login
{
public abstract class LoginScreen : Screen
{
private readonly ITextBox usernameTxb;
private readonly ITextBox passwordTxb;
private readonly IButton loginBtn;
protected LoginScreen(By locator) : base(locator, "Login")
{
usernameTxb = ElementFactory.GetTextBox(UsernameTxbLoc, "Username");
passwordTxb = ElementFactory.GetTextBox(PasswordTxbLoc, "Password");
loginBtn = ElementFactory.GetButton(LoginBtnLoc, "Login");
}
protected abstract By UsernameTxbLoc { get; }
protected abstract By PasswordTxbLoc { get; }
protected abstract By LoginBtnLoc { get; }
public LoginScreen SetUsername(string username)
{
usernameTxb.SendKeys(username);
return this;
}
public LoginScreen SetPassword(string password)
{
passwordTxb.TypeSecret(password);
return this;
}
public void TapLogin() => loginBtn.Click();
}
}
- Implement interface (Android example):
using Aquality.Appium.Mobile.Applications;
using Aquality.Appium.Mobile.Screens.ScreenFactory;
using OpenQA.Selenium;
using OpenQA.Selenium.Appium;
namespace Aquality.Appium.Mobile.Template.Screens.Login
{
[ScreenType(PlatformName.Android)]
public sealed class AndroidLoginScreen : LoginScreen
{
public AndroidLoginScreen() : base(By.XPath("//android.widget.TextView[@text='Login']"))
{
}
protected override By UsernameTxbLoc => MobileBy.AccessibilityId("username");
protected override By PasswordTxbLoc => MobileBy.AccessibilityId("password");
protected override By LoginBtnLoc => MobileBy.AccessibilityId("loginBtn");
}
}
- Resolve screen in test:
var loginScreen = AqualityServices.ScreenFactory.GetScreen<LoginScreen>();
Our library allows you to run tests on different devices and store their settings (like udid, name, etc.) in JSON files.
You have to add devices.json file to resources where you can define a set of devices which you use to run tests.
It is possible to set default device for each platform in settings.json by defining deviceKey
property which is a key of device settings from devices.json
file.
You can also create several profiles with devices by adding files with suffixes devices.<devicesProfile>.json
(like devices.set1.json
) and then specify profile using environment variable devicesProfile: set1
.
Library's source code is made available under the Apache 2.0 license.