0 Comments
 

I recently wrote a UI test for an app which displayed a CSS ID which included a colon. The UI tree from the REPL looked like this:

Googling did bring me closer to a possible solution by suggesting to escape the colon with a backslash, which ended in the following output:

So no luck, before going into any detail here is how to solve the issue:

iOS

Android

The reason why the colon has to be escaped that many times is because the string will be passed through multiple runtimes. Each will be interpreting and escaping the string anew. The differing count is due to how Xamarin UI Tests have to handle the platforms.

Reference

Many thanks to Tobias Røikjer from the Xamarin UI Testing team for pointing out how to solve this problem.

0 Comments
 

Blog title image showing github octocat and Visual Studio Logo

During this post I assume you are already familiar with GitHub. Visual Studio Team Services (VSTS) is a cloud hosted service which focuses on DevOps centric teams. You can use the integrated Git repository if you are looking for a private repository. But in case the project is already hosted on GitHub or it is an open source project. VSTS can act as a build server which supports 3rd party hosted repository. The path for integrating GitHub is one of the best predefined paths a thereby is one of those services. But it is that comes with a great support for integration.

VSTS is not a tool which is focused on a single task. It is rather a tool trying to deliver a common platform to support Teams that are living a DevOps mentality. Per default VSTS provides teams with a default tool set for source code management, build and testing. Plugins allow to bind in different tools for a certain task at hand e.g. versioning control. These plugins or external service endpoints allow to integrate GitHub as VCS with ease. I'll assume you meet the following preconditions:

  • Have a VSTS account
    • You can create your free account here.
  • Have a VSTS Project
  • Have a GitHub account
  • (Have the code repository pushed to GitHub)

Open the projects dashboard and then open the settings menu. In the Control panel of your project open the tab Services:

Tabs in the VSTS project control panel with services selected.

Then add a new service endpoint and select GitHub:

Adding a new service endpoint which includes a GitHub option.

In the following dialog give the connection a name I.e. GitHub. Note that if you are already logged in to GitHub with an account, this account will be used to make the connection. If you want to use another account. Try using the private mode of your browser while performing these steps.

Dialog for configuring the external GitHub service, simply select Authorize to proceed.

After tapping on Authorize your VSTS will be connected to your GitHub account. When configuring the build configuration for a project. It now is possible to select GitHub as the repository type I.e. select a repository hosted on GitHub.

Screen shot showing the repository tab in a build config which allows selecting GitHub as repository type.

Conclusion

In this post we saw how we can add GitHub as an external service to a VSTS project. After adding GitHub as a service. It is possible to select a GitHub repository within a build configuration. So you can now build source code from GitHub via VSTS. The integration at the time of writing is still limited to only the build process. It currently is not possible to reference code from GitHub in the planning part. Or see the repository in the code part of the VSTS web dashboard.

0 Comments
 

image

In this post we will look at how we can write UI tests for a Xamarin.Android app. The app which we are testing is a basic app based on the MVVM pattern. You can find a detailed blog post on the in and outs of the app under test here.

Assuming you already have a Xamarin Test Cloud (XTC) project added to your solution. As described in this former post. Lets get started by preparing the app for UI testing.

Enabling your Android app for the XTC tests

You do not have to do anything to enable your app to be compatible with XTC. That being said when writing a test with Xamarin Test Cloud. The test should not recognize a control by the content it is displaying. Rather it identifies a control via an ID which is not visible to the end user but rather a invisible ID. Setting this ID is best done via the accessibility label attribute. You can set this in the AXML code of your view i.e. control:

This ID will not have to change if the locale changes. Even if the location of the UI element changes it will still be found by the test. Thus IDs should be generally used to identify controls as they allow for higher resilient test code.

Writing Test(s)

After tuning our the UI code we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting off with or smaller apps (as it would be the case in this post). I usually prefer to use the REPL which is easy to use and can be invoked at any point in the test code.

When the UI is prepared accordingly we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting of with or smaller apps (as it would be the case in this post), I usually prefer to use the REPL which is easy to use and can be inserted to be started at any point in your code.

The REPL is especially useful once you have a large testing framework. Having a framework i.e. helpers in place you can run those before firing up the REPL. So you can start exploring and interacting with the UI right were you need to.

XtcTreeWithIds_thumb

Starting the REPL is as easy as adding the following line to your test method:

You can see the entire apps visual tree outlined.

Now we can define the steps we want to perform in our test:

Note how the test takes screenshots at every stage. This allows to easily identify the steps on the Xamarin test cloud and give them a label. While this might seem to be a bit of an overkill for such a small sample. When writing larger tests naming your steps i.e. screen shots will help you narrowing down where an error is happening.
One good thing about the tests is that they also run well on your local machine. So using e.g. the al Studio we can execute the tests over the NUnit Runner:

shows resharper testrunner in visual studio after executing a test

You can choose to run the tests on an emulator or device as you like. Just select the desired target as you would when starting the application. Or submit it to the test cloud i.e. integrate it in our build process.

Conclusion

This post described how to get started writing automated UI tests with Xamarin Test Cloud for a Xamarin.Android. Showing you how to adopt your UI for writing resilient test. Based on NUnit the tests are running on a stable and battle proven foundation.

Keep in mind that UI tests should not be the only testing you rely on for testing your app. But in combination with Unit and Integration tests they can provide great value to your project. Running them on Xamarin Test Cloud allows you to run them on a sea of devices. Along with different versions of Android i.e. vendor flavours.

You can find the entire sample on GitHub.

0 Comments
 

Title image showing the xamarin test cloud and ios logo

In this post we will look at how we can test a Xamarin.iOS app which is based on a storyboard. The app which we are testing is a basic app based on the MVVM pattern. You can find a detailed blog post on the in and outs of the app under test here.

Assuming you already have a Xamarin Test Cloud (XTC) project added to your solution as described in this former post. Lets get started by preparing the app to be tested.

Preparing the iOS for the XTC tests

When writing a test with Xamarin Test Cloud the test ideally does not recognize a control by the content it is displaying but rather via an ID which is not visible to the end user but rather a invisible ID. Setting this ID is best done via the accessibility label attribute which can be set in the storyboard under properties:

Shows where under properties the label can be enabled.

This ID will not have to change if the locale changes or the UI element is moved to a different location and therefore will allow you to write more resilient test code.

Writing Test(s)

When the UI is prepared accordingly we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting of with or smaller apps (as it would be the case in this post), I usually prefer to use the REPL which is easy to use and can be inserted to be started at any point in your code.

The REPL is especially useful once you have a substantial testing framework written because it allows you to execute it after executing some prearranged steps to get to a certain point which you would like to test.

Shows repl output of the app

Starting the REPL is as easy as adding the following line to your test method:

You can see the entire apps visual tree nicely outlined.

Now we can define the steps we want to perform in our test:

Note how the test takes screenshots at every stage. This allows to easily identify the steps on the Xamarin test cloud and give them a label. While this might be a bit overkill for such a small sample on larger tests when named right the steps and screen shots will greatly help you narrowing down where an error is happening.
One good thing about the tests is that they also run well on your local machine. So using Xamarin Studio on a Mac we can simply execute the tests over the NUnit Runner:

image showing the nunit test runner of xamarin studio.

Or submit it to the test cloud i.e. integrate it in our build process.

Conclusion

This post described how to get started writing automated UI tests with Xamarin Test Cloud for a Xamarin.iOS application. After some minor adjustments to the UI a test can be written using the familiar NUnit testing framework. Keeping in mind that UI tests should not be the only testing you apply to your app since they are rather slow, they do bring a lot of value when used properly since one can easily run the tests on different devices and iOS versions with the Xamarin Test Cloud.

You can find the entire sample on GitHub.

0 Comments
 

title image showing 1s and 0s in a green console style.

Running your tests on Xamarin Test Cloud (XTC) is as easy as right clicking onto tests and select run in XTC. As easy as this approach is – as limited it becomes when more sophisticated demands arise. Those might be running a group of tests, running on preconfigured device groups or integrating into an automated Continuous Integration (CI) and Continuous Deployment (CD) process. But there are also some additional useful features and information which we shall see in the follow up of this blog post.

Thereby the focus will be on the following:

  • Creating and Running the basic Command
  • Setting Categories and using them in the Command
  • Recording your Android XTC test runs
  • Using the XTC API to retrieve even more information

So lets get started Smile 

The basics Command

The easiest way to get a test script is if you login to the Xamarin Test Cloud dashboard website. Click on New Test Run, now you can either select an existing app or just choose to create a new App, select a team, devices that should be included in the test run and some additional information such as series, device locale and parallelisation. In the last step a sample script is generated which is the basic recipe for running the tests from the command line.

Now this script has to be adopted at the various points to reflect the setup of the app under test but from there on simply navigate to the root e.g. the solution folder and execute the script from the command line, power shell or the shell of your choosing. The tests will be uploaded and run on the selected devices. Once the tests are completed the results can be viewed in the XTC dashboard.

Running specific categories of your test suite

XTC allows to set categories when declaring a test as follows:

Categories allow to choose a subset of the tests to be run when executing them on the XTC. This can be a great way to create fast running smoke tests that give instant feedback after a build or running focused tests on a area of the app. The command can be extended by adding the following parameter:

If applicable one choose multiple categories for one run which makes mix and matching an easy undertaking. So a command using e.g. the categories SmokeTest and Purchase would be the following command:

Okay now to becoming more insights into tests, which is especially interesting when they are failing…

Recording your test runs

The basic option to get a better sense of what is going on during a test run is taking screenshots. This can be done by adding the following line to your tests as follows:

Note taking screenshots might increase the duration of a test run, in case of large suites one might want to reduce the overall time by using a constant within the UI test project that enables/disables detailed reporting of the test runs.

Now screenshots are already a great help. But in case of Android you are able to record the test runs. How awesome is that?! Enabling recordings is as easy as adding an additional parameter to the command line:

The recording can be viewed on the test dashboard with the very usable feature of speeding up the playback so you wont be bored by watching how your test fights it’s way to the juicy part. And as of date of writing recordings are only available for Android and can be solely enabled by adding the parameter to the Command Line Interface (CLI). If you try to use the command on an iOS run there will be no exceptions but the recording will just simply be missing.

Also don’t forget to add a good failure message to the Assert. Or you will be left with the reason of a failed test because an expected value was false instead of true (not helpful for me…).

Accessing the XTC API

Invoking tests via the command line is a great way to integrate UI tests running on XTC to an automated DevOps build pipeline. By default adding the following parameter to the command will allow to receive an NUnit Test report, it gives a very high level report of the run i.e. will show which tests have failed but not on which device etc.. If you desire to have a richer interaction with the data you can start interacting with the Xamarin Test Cloud API. There is a ton of information you can retrieve about a test run when using the API. Unfortunately at the current time it is not possible to retrieve images, recordings and some other information. If you are interested in giving the team an initiative to retrieve this information you can vote for this feature here.

All in all if you are using an on premise or other third party dashboard for displaying your test results, make sure you check out the API as it may just provide the more detailed information you are looking for and do not find within the NUnit test-report.

Conclusion

Starting test runs for Xamarin Test Cloud from the command line not only lets you integrate it into a DevOps toolchain but also allows you to run sub-sets of your tests, or record your test runs for Android. Last but not least if you are interested on feeding your test results into a dashboard the Xamarin Test Cloud API might just provide you with the information you are looking for.

The command line option is not only valuable for integration into automated toolchains but also for a more granular control when executing the tests locally. Be it from Windows or OSX the Xamarin Test Cloud toolchain has you covered.