106007

Xamarin.UITest review: QA-engineer’s standpoint

By EGO Angel 2 years ago
Home  /  Developer's tools  /  Xamarin.UITest review: QA-engineer’s standpoint
bg3

Hi to everyone! Today our QA engineer Andrew would like to share his experience in using of Xamarin.UITest. He has wrote a cognitive article which we with pleasure present to your attention. Thank you for reading us, hope this material will be useful for you!

Xamarin.UITest – is a Xamarin`s  Automated UI Acceptance Testing framework based on Calabash.

So, what is it and how to cook it

Xamarin.UITest based on Calabash and have a similar operating principle. However, in this framework tests are being written by С# and NUnit (in difference with Calabash in which Gherkin+Ruby is used).This framework is cross platform, that`s why it allows to create crossplatform tests, both on iOS and Android. Windows Phone is not supported and Andrew personally think it is a disadvantage of this tool. But on the other hand this tool supports tesing of native apps on Java and Objective-C.

image06

What are the advantages of Xamarin.UITest

Surely the most of you can oppose that there are native frameworks for Java and Objective-C that make a good job of it. But if you need to write UI Acceptance Testing simultaneously for both platforms, Xamarin.UITest will be very useful. Moreover there is native Xamarin Test Cloud support . Test Cloud is very useful but rather expensive.

More about how it works

Work mechanism on OS and Android is different. Nuget package is embedded in iOS app, it raises an http server inside your application. That`s how it works:

image03

It is performing a little different on Android . During tests’ assemly and launch , two apps are being installed on the device: your app and Test Cloud server. Both of them are signed by the same key. That`s why Test Cloud server has rights on managing your app. It`s looks like this:

image05

Xamarin.UITest embeds in solution rather easy, almost in a couple of clicks. You just need to create another one project for UI tests.

image00

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

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

If you use Xamarin`s IDE the integration can be considered as completed. For Visual studio you’ll have to make all the actions manually. But it is rather simple. Besides the actions with iOS project you need to add PCL project and install Nunit and Xamarin.UITest packages into it.

If you use Xamarin`s IDE the integration can be considered as completed. For Visual studio you’ll have to make all the actions manually. But it is rather simple. Besides the actions with iOS project you need to add PCL project and install Nunit and Xamarin.UITest packages into it.

Now let`s talk about our tests’ configuration

We are interesting in two classes: Tests and Appinitializer. Let`s start from the second one:

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 ();
        }
    }

There is parameter set  besides mentioned in TODO way to apk and ipa files. For example, the device ID where tests will be launched, api key for Xamarin Test Cloud and others. The class defines a platform for running and launches the tests on the selected platform. Now let`s consider 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 SetUp attribute will run our tests and transfer them to StartApp platform.Unfortunately “native” variant will work only for Xamarin.Forms project. On MVVM-Cross you can make something 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
        }

Thus, you need to create TestiOS and TestDroid targets.

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

Tests are usually have standart Arrange-Act-Assert strucrure. You should   test that contains  Repl (read-eval-print-loop ) method. It runs the console where  we can see the structure of visible part of our application. This is done as follows:

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

This method calls REPL console. For clarity, Andrew executed tree command there, it retreives  information for all visible elements:

image01

And the app looks like this:

image02

To interact with control  elements we need to use the IApp interface methods. In this article we will consider just three of them: Tap(), WaitForElement() and Query(). Though there are much more of them and here you can find  the full list with  their properties.

First  we have to get the identifiers of AppQuery type elements. This is done as follows:

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");

Well, we have got AppQuery for all elements and now we can interact with them. Let`s validate the startup message, tap on the button and validate 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, IApp methods (the instance in this case is app) take as input AppQuery data type parameters and return an AppResult[] type result. But for all that Linq expressions only applicable to AppResult[], thus assertions and AppResult[] looks like this:

image04

In this example, during the local launch  tests can be started  concurrently on both platforms, and all the results will pour in one console (in Andrew`s opinion it`s not very conveniently). In addition, in a couple of clicks you can integrate Xamarin service TestCloud and run tests in the cloud. A test launch is made from unit tests panel, what  is quite convenient.

Except tests running agent you need to add api key in TestCloud (Andrew didn`t put it in this sample). You can learn how to get and to use it here.

Link to the sample that was used in this article is here.

Useful links:

https://developer.xamarin.com/api/namespace/Xamarin.UITest/

https://developer.xamarin.com/guides/testcloud/uitest/intro-to-uitest/

http://www.nunit.org/index.php?p=quickStart&r=2.6.3

https://msdn.microsoft.com/ru-ru/library/bb397926.aspx

At this point we are finishing our brief excursion into Xamarin.UITest. I hope Andrew`s review was useful for you. Thank you for your attention and see you soon in our blog!

Categories:
  Developer's tools, EGO inside, EGO meetups, Tech news
this post was shared 0 times
 400