Test Cloud and Unit Testing (Day 14)

Testing the UI and unit testing the code is essential in all enterprise level apps. If you have followed and setup your project in a similar style to the xarch-starter project, then testing is going to be quite easy.

Unit Testing

Everyone should be fairly familiar with Unit Testing so I won’t go into many details here. When doing any MVVM architecture it makes testing the UI code programmatically quite easy. Unit test against the Model. For each action, the state of the model, (its properties) should change to what you expect. Simple and easy to test.

The only issue is testing PCL’s, which needs certain support. I prefer to use xUnit and if you are just testing the PCL then it works nicely in Visual Studio or their console.

If you need to test in a specific environment, you can use one of their runners. Greg Shackles actually has a create quick start guide for Testing Xamarin Apps with xUnit.

UI Testing and Test Cloud

One of the great things about Xamarin is the ability to do UI testing via their Test Cloud. Even low level accounts in Xamarin get a little bit of Test Cloud usage. Small caveat, no Windows support, only iOS and Android are support with UITest.

For setting up UITest have a read of Introduction to Xamarin.UITest.

The way UI Testing works is you use the StyleId to create a unique Id for each element on your page. Then during your test you retrieve that element, most commonly through app.Query(m=>m.Marked(“MyStyleId”)).FirstOrDefault();

Note: Make sure you look at MainActivity.cs for Android (the ViewInitialized event) and same again in AppDelegate.cs. This is needed for Xamarin Forms because it copies the StyleId from your Xamarin Forms view to the appropriate native control property so that you can now use the Id in UITest.

Update (18th April 2016): As of Xamarin Forms 2.2.0-pre1 there is now a field called AutomationId. This is now to be used to reference controls in UITest, instead of the above method.


This is the best way to get to learn the UITest commands without having to run tests again and again until you get it right. In any of your UITest unit tests, add the line app.Repl(); When this test runs you will be shown a window which you can write commands and see what is currently available in the Visual Tree.

Screen Object Pattern

We sometimes forget that we are coding when writing tests. With this we seem to forget object orientated principles and start writing huge hard to maintain tests. A great pattern to follow is the Screen Object Pattern. Instead of referencing the UI objects directly in each test you create a class that is responsible for interacting with the screen. For example the Login Screen.

Then you can call this from your tests. If your screen changes you only have one place to change to update all your tests.

Test Recorder

At the time of this blog post, Test Recorder it is still in preview and hence isn’t complete and has known issues. It does now work with Xamarin Forms after a brief issue earlier on. This allows you to automatically create UITest scripts by performing the actions on a device and having them recorded.

It is an easy way to generate Test Scripts fast though you might need to clean the scripts up at the end depending on the architecture you setup for your tests.

5 Common Pitfalls In Enterprise Mobile Development

Based on my experience, of over 9,000hrs of Xamarin.Forms development, check out some of my hard learnt lessons, in enterprise Xamarin.Forms development.

<< Debugging And Error Tracking (Day 13) || API MicroService and Cross Continent Scalability (Bonus) >>

14 Days To Building An Enterprise Quality Xamarin Forms App