Xamarin.UITest

In this article I will tell you about Xamarin.UITest - the framework for acceptance UI testing from Xamarin.

What is it and how to cook it

Xamarin.UITest is based on Calabash and has a similar working principle. However, tests on this framework are written in C # and NUnit (unlike Calabash, which uses Gherkin + Ruby). The framework is cross-platform and, therefore, it allows you to write tests for both the iOS platform and Android. Windows Phone is not supported, which I personally consider a disadvantage of this tool. But it supports test native applications in Java and Objective-C.

Why Xamarin.UITest

Of course, many of you may argue, they say, Java and Objective-C have their own native frameworks that do an excellent job with their task. But if you need to write acceptance UI tests simultaneously for two platforms, Xamarin.UITest will come in handy. Moreover, it has box support Xamarin Test Cloud . The testclaud itself is a very useful thing, but rather expensive.
')

Learn more about how this works.

The mechanism of work on iOS and Android is different. On iOS, the Nuget package is built into the application, which raises the http server inside your application. Here's how it works on iOS:



When working with Android, things are a little different. In fact, when building and running tests, two applications are installed on the device: yours and Test Cloud server. Both of them are signed with the same key, so the Test Cloud server has rights to manage your application. It looks like this:



Embedded Hamarin.UITest in a solution is quite simple, almost in a couple of clicks. All you need is to create another project for UI tests.



After these simple actions, a project with an initialization template and installed packages is added. Then, in the iOS project, you need to add the Nuget package Xamarin Test Cloud Agent NuGet, and in AppDelegate we write the following lines:

#if DEBUG Xamarin.Calabash.Start(); #endif return true; 

If you are using marinated IDE, then the integration process can be considered complete on this. For Visual studio, you have to do everything manually, but everything is pretty simple here. In addition to manipulating the iOS project, you need to add a PCL project and install the Nunit and Xamarin.UITest packages into it.

Now let's talk about configuring our tests.

We will be interested in two classes: Tests and Appinitializer. Let's start with the second:

 public class AppInitializer { public static IApp StartApp (Platform platform) { // TODO: If the iOS or Android app being tested is included in the solution // then open the Unit Tests window, right click Test Apps, select Add App Project // and select the app projects that should be tested. if (platform == Platform.Android) { return ConfigureApp .Android // TODO: Update this path to point to your Android app and uncomment the // code if the app is not included in the solution. //.ApkFile ("../../../Droid/bin/Debug/xamarinforms.apk") .StartApp (); } return ConfigureApp .iOS // TODO: Update this path to point to your iOS app and uncomment the // code if the app is not included in the solution. //.AppBundle ("../../../iOS/bin/iPhoneSimulator/Debug/XamarinForms.iOS.app") .StartApp (); } } 

In addition to the path to the apk and ipa files specified in TODO, there are a number of parameters, for example, the device identifier on which the tests will be run, the api key for Xamarin Test Cloud and others. The class itself determines the platform to run and starts the tests on the selected platform. Now let's look at the Tests class:

 public class Tests { IApp app; Platform platform; public Tests(Platform platform) { this.platform = platform; } [SetUp] public void BeforeEachTest() { app = AppInitializer.StartApp(platform); } [Test] public void AppLaunches() { app.Repl(); } } 

The method with the SetUp attribute and will run our tests by passing a platform to StartApp. Unfortunately, the “out-of-the-box” version will only work for a project on Xamarin.Forms. And on MVVM-Cross, you can somehow get out like this:

 public void SetUp () { #if TestiOS Path = "path/to/app"; _app = ConfigureApp.iOS .AppBundle(Path) //Xcode ->Window ->Devices -> Identifier .DeviceIdentifier("Identifier") .StartApp(); #else Path = "path/to/apk"; _app = ConfigureApp .Android .ApkFile (Path) //.EnableLocalScreenshots () .StartApp (); #endif } 

Accordingly, it is necessary to create TestiOS and TestDroid targets.

Well ... set up, launched, it's time to start writing tests!

Tests usually have quite standard Arrange-Act-Assert structure the same Nunit, only in a profile . We should start by creating a test containing the Repl method (read-eval-print-loop). It launches a console in which, using queries, we can see the structure of the visible part of our application. This is done like this:

 [Test] public void AppLaunches() { app.Repl(); } 

This method calls the REPL console. For clarity, I executed the tree command in it, providing information on all visible elements:



And the application itself looks like this:



In order to interact with the controls, we need to use the methods of the IApp interface. In this article, we will consider only three of them: Tap (), WaitForElement () and Query (). Although they are much larger, and their full list with all the properties can be found here .

First we need to get the identifiers of the elements of type AppQuery. This is done like this:

 static readonly Func<AppQuery, AppQuery> InitialMessage = c => c.Marked("MyLabel").Text("Hello, Habrahabr!"); static readonly Func<AppQuery, AppQuery> Button = c => c.Marked("MyButton"); static readonly Func<AppQuery, AppQuery> DoneMessage = c => c.Marked("MyLabel").Text("Was clicked"); 

So, we received AppQuery for all elements and now we can interact with them. Let's validate the start message, tap on the button and validate the received message.

 [Test] public void AppLaunches() { app.Repl(); // Arrange - Nothing to do because the queries have already been initialized. AppResult[] result = app.Query(InitialMessage); Assert.IsTrue(result.Any(), "The initial message string isn't correct - maybe the app wasn't re-started?"); // Act app.Tap(Button); app.WaitForElement (DoneMessage, "Timeout", TimeSpan.FromSeconds (2)); // Assert result = app.Query(DoneMessage); Assert.IsTrue(result.Any (), "The 'clicked' message is not being displayed."); } 

As you can see from the example, IApp methods (the instance in this case is app) take as input parameters the data of type AppQuery and return the result of type AppResult []. Linq expressions are applicable only to AppResult [], and therefore the asserts look like this. And AppResult [] itself looks like this:



In this example, when running locally, tests can run in parallel on both platforms, and all the results will be dumped into one console (which, IMHO, is not very convenient). In addition, it is possible in a couple of clicks to integrate the maritime TestCloud service and run tests in the cloud. Running tests is done from the unit test panel, which is quite convenient.

In addition to the agent, in order to run tests in TestCloud, you need to add an api key (I did not add it in this sample). How to get it and apply is described in detail here .

On this, perhaps, it is worth completing our brief excursion into Xamarin.UITest. I hope my review was useful to you. Thank you all for your attention.

Link to the sample that was used in the article.

Useful links on the topic:
developer.xamarin.com/api/namespace/Xamarin.UITest
developer.xamarin.com/guides/testcloud/uitest/intro-to-uitest
www.nunit.org/index.php?p=quickStart&r=2.6.3
msdn.microsoft.com/en-ru/library/bb397926.aspx