Unit Testing Shared Code

First let’s take a look at writing tests for the shared code. To have something to test, I have added another page to CiCdApp , but more importantly I have added a page model. If you are familiar with the Model-View-ViewModel (MVVM) pattern , you will know that each page has a corresponding page model that contains all the properties and logic for a certain view.

The page and page model I have added to my Portable Class Library (PCL ) project are named CalculatorPage and CalculatorPageModel. They will contain simple logic to add and multiply two numbers, as well as giving you the answer to life, the universe, and everything. Since these are unit tests and not UI tests, I will be focusing on the page model.

Before discussing the code that I have created for this, I will zoom in a bit on the PCL project I just mentioned. If you have developed Xamarin apps before, you might have heard about so-called shared projects and PCL projects. These types of projects are the ways to share code for Xamarin apps . Describing the differences in detail would be beyond the scope of this book, but for clarity I will briefly describe the basics.

A PCL project will compile into a DLL file, while a shared project is nothing more than a folder with code that is shared between the platform projects. When compiling the code in a shared project, the code will become part of the platform project and is an integral part of the assembly.

The Portable Class Library was a first attempt by Microsoft to create a cross-platform library with which you can share code. For a while it was only cross-platform between Microsoft platforms, but with the support in Xamarin, it became more popular because it now actually supports multiple platforms. In time, .NET Standard Libraries will probably replace the PCL or at least become more popular.

The biggest difference between the two lies in the support for features of the .NET framework. With shared projects, you have access to all features of the .NET framework. You can differentiate code for the separate platforms with compiler directives. In a PCL project, you specify the platforms that you want to support, and the features of the .NET framework that are available to you are dependent on that selection. You will get support only for the functionality that is available on each platform that you want to support. Of course, there are ways to implement platform-specific code for PCL projects as well.

Each solution has its pros and cons, and basically it comes down to a matter of taste because both solutions achieve the same result. I personally tend to like the PCL projects. The code is more separated and is easier to reuse. It just feels cleaner.

Now that you have learned about what a PCL is, let’s take a look at the page model I have added. The implementation looks like this:

public class CalculatorPageModel
{
    public ICommand AddCommand { get; private set; }
    public ICommand MultiplyCommand { get; private set; }
    public ICommand AnswerToEverythingCommand { get; private set; }

    public int ValueA { get; set; }
    public int ValueB { get; set; }
    public int Result { get; set; }

    public CalculatorPageModel()
    {
        AddCommand = new Command(Add);
        MultiplyCommand = new Command(Multiply);
        AnswerToEverythingCommand = new Command(AnswerToEverything);
    }

    private void Add()
    {
        Result = ValueA + ValueB;
    }

    private void Multiply()
    {
        Result = ValueA * ValueB;
    }

    private void AnswerToEverything()
    {
        Result = 1337;
    }
}                                                                              

As you can see, there is nothing exciting going on here, but it gives you some code to write tests for.

Now you just add a regular unit test project to your solution. In Figure 6-4 you can see the Add New Project screen where you can select the Unit Test Project template.

Figure 6-4. Adding the unit test project to the solution

After Visual Studio does some generating, you will have a bare setup of a unit test fixture in the UnitTests1.cs file. If you look a bit closer, you will notice the structure is much like the Test Cloud test structure. The naming convention on the attributes is a bit different, but the way you write tests is the same.

In the following code block, you will see how I defined test cases for my methods in the page model:

[TestClass]
public class CalculatorUnitTests                                                
{
    private CalculatorPageModel _pageModel;

    [TestInitialize]
    public void Initialize()
    {
        _pageModel = new CalculatorPageModel();
    }

    [TestMethod]
    public void AddTest()
    {
        // Arrange
        _pageModel.ValueA = 20;
        _pageModel.ValueB = 22;

        // Act
        _pageModel.AddCommand.Execute(null);

        // Assert
        Assert.AreEqual(42, _pageModel.Result);
    }

    [TestMethod]
    public void MultiplyTest()                                                                              
    {
        // Arrange
        _pageModel.ValueA = 6;
        _pageModel.ValueB = 7;

        // Act
        _pageModel.MultiplyCommand.Execute(null);

        // Assert
        Assert.AreEqual(42, _pageModel.Result);
    }

    [TestMethod]
    public void AnswerToEverythingTest()
    {
        // Arrange
        // Nothing to arrange for this test

        // Act
        _pageModel.AnswerToEverythingCommand.Execute(null);

        // Assert
        Assert.AreEqual(42, _pageModel.Result);
    }
}

As I just mentioned, there are a few different terms here: TestFixture is now a TestClass, SetUp is now a TestInitialize, and Test is now a TestMethod. Other than that, the concepts are the same. You will notice that in the initializer method I create a reference to the page model. This method—just like the method marked with the SetUp attribute in the UI tests—will be executed before each test. This way, you get a fresh state of the page model so one test does not influence the other. Also, just like the UI tests, you can follow the Act-Arrange-Assert pattern for the unit tests as well.

The body of the test methods should be pretty straightforward. However, I did make a mistake. In the page model, I return the number 1337 as the answer to life, the universe, and everything, but of course this should be 42. (Obviously!) So, you will know this test will fail. The other tests should pass.

When you right-click the unit test project, there is the option Run Unit Tests to run all the tests in the project; you can also do this per class or even per test method. When you run them, the projects will be built, and the Unit Test Sessions screen will pop up showing you the progress of the selected tests. Figure 6-5 shows you the output of the tests I have created.

Figure 6-5. Output of the test run

As expected, one test failed, and it tells you exactly why. I will not fix it now, so you can see the output in VSTS as well. As your test cases are becoming more complex, you might want to debug it to see whether your test is wrong or your code is wrong. In the same context menu where you first started these tests there is also the option Debug Unit Tests . With these options you can set breakpoints like you regularly would and step through your code, analyzing what is going wrong.

The true power of your test lies with running them in an automated and continuous fashion. Because unit tests should be small and can execute within seconds, they can and should be part of your continuous integration build. This way, you receive feedback about the quality of your code as soon as possible.

To achieve this, just go to your build definition and add a new step. Find the Visual Studio Test step and add it to your definition. You should add this after your main project or solution has been built since the tests cannot be run when the project does not build at all.

There are some options for you to configure, but with the default configuration you should be able to get started.

In Figure 6-6 you see the added step and configuration . There are two things that should be noted in the configuration. The first thing is the value in the first field, Test Assembly . With this field, you specify the assembly or assemblies in which your tests are. You can work with minimatch patterns to locate them. By default, VSTS should pick up all assemblies with test in them, excluding the ones under the obj folder. As you might remember from the previous chapter, the Test Cloud assemblies also have test in them, so make sure you exclude them as unit tests. That is why it’s a good idea to name your projects differently so you can distinguish them by name.

Figure 6-6. Adding unit tests to your build definition

The second thing you might want to do is select the Code Coverage Enabled check box . With this enabled, it will also collect data about the code coverage. This means it will tell you how much of your code is tested by the unit tests that are found; the closer you get to 100 percent, the better. As you may recall from the UI tests, you can select the “Continue on error” box here as well to not fail your build when one or more tests fail but rather have the build marked as Partially Succeeded.

All results, including the data on the code coverage, are consolidated in the results of a build, right in VSTS, just like you saw with the UI tests. Looking at Figure 6-7, you see a similar screen with tests results as in the previous chapter with Test Cloud.

Figure 6-7. Unit test results in VSTS

If you combined these types of tests in one build definition, the results would be aggregated here and the combined output would be shown.

Unit Testing Android- and iOS-Specific Code

For unit testing a traditional Xamarin app or some platform-specific code you might have, special templates are available in Visual Studio. If you look back at Figure 6-4, you can also see templates specifically stating Unit Test App for both Android and iOS.

When you add one of these to your solution, you will notice that it differs a bit from regular unit tests. Where regular unit test projects output a library containing your tests, these projects are actual apps. Figure 6-8 shows you my Solution Explorer window in Visual Studio after adding the Android and iOS unit test projects.

Figure 6-8. Solution Explorer window with the all the current projects

When you examine the contents of these projects, you will see that they have everything in there to be fully qualified apps, which can be run on an emulator. Besides that, there is one file in there: the TestSample.cs file .

Running these tests is done through a test runner by default. This means that if you run these projects, you are presented with an app that can run the tests for you and provide you with the results. Before you take a look at that, let’s take a quick look at the content inside the test classes. Since they are identical in each platform, just one is shown here:

[TestFixture]
public class TestsSample                                                
{
    [SetUp]
    public void Setup() { }

    [TearDown]
    public void Tear() { }

    [Test]
    public void Pass()
    {
        Console.WriteLine("test1");
        Assert.True(true);
    }

    [Test]
    public void Fail()
    {
        Assert.False(true);
    }

    [Test]
    [Ignore("another time")]
    public void Ignore()
    {
        Assert.True(false);
    }

    [Test]
    public void Inconclusive()
    {
        Assert.Inconclusive("Inconclusive");
    }                                                                              
}

Once again, you see test fixtures that are similar to what you have seen before. Better yet, the attributes you can work with are the same ones as the tests you wrote for Test Cloud.

To show you how to run the tests, I will just use these sample ones for now. Set either one of these platform unit test projects as the startup project and run it like you would run your app normally. Figure 6-9 shows both the iOS Simulator and the Android emulator side by side with the test runner app.

Figure 6-9. Test runner on Android (left) and iOS (right)

This app searches within the same binary to see whether there are any tests available and lists them within the test runner interface. From there you can select one or more tests and run them from inside the app. Also, the results are presented to you so you can examine the outcome.

While the test runner will suffice for running the tests locally, it imposes a problem when implementing this way in an automated pipeline environment. You cannot run an app, fire the tests through there, and fetch the results from an emulator window.

These tests can be automated, but it takes some effort. Also, for Android it is easier than iOS. For more information on how to set this up, please refer to https://spouliot.wordpress.com/2012/04/02/touch-unit-automation-revisited/ for iOS and https://developer.xamarin.com/guides/android/troubleshooting/questions/automate-android-nunit-test/ for Android.