Over a million developers have joined DZone.

Mobile Test-Driven Development: Part 2

DZone 's Guide to

Mobile Test-Driven Development: Part 2

In this tutorial series, we explore best practices for mobile development code quality and testability. Today we look at testability with TinyIoC containers.

· Mobile Zone ·
Free Resource

This post is the second in a series about TDD in mobile development. The first part of this series can be found here.

In the previous post, we looked at writing unit and integration tests for platform-specific code in Android and iOS. Also, I promised to show you in the next post how to write cross platform unit tests that would assert your logic once and for many platforms. However, in order to do that, you need to first consider how testable your code is.


In order to write good unit tests and have good test coverage around your code, you need to first consider code testability. There are many books and blogs that talk about testability; I find these posts good for demoing and communicating the basics of what is needed. They can be found here and here.

Basically, your classes/libraries need to declare upfront what dependencies they have. It is not acceptable to have classes that just instantiate (using the new keyword or otherwise) other classes, or invoke static methods/fields from other entities. You might ask, why? I am glad you asked. That’s because such classes/libs are not testable. You cannot mock/fake/change their internal behaviors. To make things worse, some of these external dependencies or static classes might be platform dependent or might require certain environment context to return certain output, which means such code would be only testable in few small scenario cases. Even worse, using static methods gives you more of a headache when it comes to thread safety, which is another topic by itself.

Therefore, your code should be clean enough and declare its dependencies upfront, so that we can test it separate from other dependencies. For that, the concept of Inversion of Control (IoC) was introduced. IoC containers enable developers to register dependencies at the start of the application in a central point to have better visibility of dependencies and to allow for better testability.

There are many IoC containers out there, but very few of them are fit for mobile development. Also, many of these containers are more geared towards large projects with lots of features that are not relevant to mobile apps. I found this question and answers on StackOverFlow, which talks about the popularity and suitability of the latest IoC containers. In our case, we have been happy with TinyIoC.


TinyIoC is a great light container that allows you to register your entities for the whole app domain. It’s light enough to be included in most small projects, yet feature-rich enough to offer convenience and flexibility to developers. We have been using it for quite a while now and previously my colleague Mark T. has blogged about it here. TinyIoC comes with mainly two files, the container itself and a small light-weight messengerHub that can be used for communicating messages across different entities/libraries. The bad news for me was that TinyIoC is platform specific, so I had to include one library in Android and a different one in iOS. Plus, I could not take that part of my code to my Portable class libraries. So, I started thinking about getting this into the next level.

Portable TinyIoC

I forked TinyIoC on GitHub, and simply enough, I got it to compile as a portable library (profile 102) that could be used on the following platforms:

1. Xamarin.Android.
2. Xamarin.iOS.
3. Windows Phone 8.1+.
4. .NET 4.0.3+.

All I needed to do was to separate the library into two different parts: a TinyIoC.Core which targets .NET 4.0 (old Reflection API), and a Portable Wrapper that targets Portable profile (102). Now we have a Portable TinyIoC, which you can find on my Github account here. I am still working on making it a Nuget Package or submitting a pull request, but so far I have it working in a stable condition and I have all unit tests passing.

Examples of Using TinyIoC on iOS

Like with most IoC containers, you need to register your dependencies (or set auto-discovery to "on"), so at the start of the app, we register like this:

publicstaticclassBootstrap {
    publicstaticvoidBuckleUp(AppDelegate appDelegate) {
        TinyIoCContainer.Current.Register < ITinyMessengerHub, TinyMessengerHub > ();
        TinyIoCContainer.Current.Register < AppDelegate > (appDelegate);
        TinyIoCContainer.Current.Register < ILogger > (TinyIoCContainer.Current.Resolve < Logger > ());
        TinyIoCContainer.Current.Register < ICloudMobileDataService > (TinyIoCContainer.Current.Resolve < AzureMobileService > ());
        TinyIoCContainer.Current.Register < IUserRepository > (TinyIoCContainer.Current.Resolve < UserRepository > ());

As you can see, this Bootstrap class gets called from the main AppDelegate, passing it a reference to the app delegate, and it will register all dependencies. Remember that you need to register your dependencies in order, otherwise you might end up with exceptions. The great thing about this is, not only could you mock pretty much everything and test however you want, but you also do not need to repeat instantiate all dependencies to get a certain entity. As an example, if your viewModel takes three parameters in the constructor, all of these are other entities (cloud service, repository, etc), you only need to use container.Resolve()  and it will get you your entity with all its dependencies- bingo!

Also, TinyIoC manages any disposable objects and disposes of them properly.

Examples of Using TinyIoC on Android

On Android, you would not notice much difference, except in the placement of the entry point ( BuckleUp() ), which in this case gets called from within the MainLauncher activity. Our Android bootstrap would look like this:

publicstaticclassBootstrap {
    publicasyncstaticTask BuckleUp(IActivity activity) {
            TinyIoCContainer.Current.Register < ITinyMessengerHub, TinyMessengerHub > ();
            TinyIoCContainer.Current.Register < IApplication > ((IApplication) Android.App.Application.Context);
            TinyIoCContainer.Current.Register < IActivity > (activity); // more code is omitted         }}

In conclusion, I have shown how simple and elegant it is to use IoC containers. I prefer TinyIoC because it is very light and now we have a portable version of it, so you have no excuse anymore. Start looking at integrating TinyIoC.Portable into your next mobile project and I would love to hear your thoughts. In the next post, we will look at Cross-Platform Unit Testing.

(Author's Note: I wrote this post back when TinyIoC was the only one I knew that worked well on Xamarin. Since then, many IoC containers have added/implemented support to Xamarin platforms and some of them are even better than TinyIoC. Therefore, I would suggest that you look into using one of these IoCContainers. This blog post has a good list of a few, with code samples and comparisons. At the moment, I am using AutoFac on Xamarin and it works great.)

mobile ,tdd ,mobile testing ,tutorial ,mobile app development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}