Over a million developers have joined DZone.

Mobile Test-Driven Development: Part 1

DZone 's Guide to

Mobile Test-Driven Development: Part 1

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

· Mobile Zone ·
Free Resource

This post aims at exploring the best practices in terms of code quality and testability for mobile development. It is part of a series that talks about unit and integration testing in the mobile space. In particular, I focus on Android and iOS.

For many developers, testing is an afterthought, and it is a task that ’s not well considered. But, there ’s heaps of research out there that shows you how much you could save and how test-first could improve your design. I am not going to go into the details of this, but I would assume that you are a test-first kind of person since you are reading this, so let’s get started.

NUnit Lite

In this post, I will show NUnit Lite for Xamarin.Android and Xamarin.iOS. NUnitLite, as the name indicates, is a cut-down version of NUnit. There are versions (builds) for testing iOS apps and for Android. The iOS comes out of the box when installing Xamarin, and it allows you to create a project from a template of NUnit Lite (MonoTouch) project.

This approach is good when you have a platform-specific code that has to be placed in the platform-specific or inside the app project. You could reference your MonoTouch or MonoDroid projects from the NUnitLite project and start your testing.

For Android, there are few versions of NUnitLite, I have worked with this one.

Sometimes, you are developing a component that needs to behave the same way on the two different platforms, but the internal implementation could be platform-specific. To test the platform specific, you put your code into your testing project as normal. But you could also Reference the same NUnitLite test file from both platforms to test both platforms, since it is the same expected behaviour on both platforms. Some developers do not like to have referenced files (me included), so you could create different versions for the two platforms if you wish to do so.

A sample of iOS platform-specific code:

public class TestableController: UIViewController {
    public TestableController() {}

    public int GetTotal(int first, int second) {
        return first + second;


A sample of Android platform-specific code:

namespace Tdd.Mobile.Android {
    public class TestableController: Fragment {
        protected override void OnCreate(Bundle savedInstanceState) {

        public int GetTotal(int first, int second) {
            return first + second;


Please note that I am not suggesting that you write your code this way or put your login into the UIViewControlloer or Activity classes. The only reason I am doing it this way is to show you how you could test anything inside these platform-specific classes. Ideally, you would put your logic into ViewModels or another form of container that is injected into the controllers. Anyway, assuming that we have some platform-specific logic inside these classes, this is how I would test it.

public class TestableControllerTest {
    public void GetTotalTest() {
        // arrange
        var controller = new TestableController();

        // act
        var result = controller.GetTotal(2, 3);

        // assert
        Assert.AreEqual(5, result);

The screenshot below shows the structure of my solution. I have also put the code on GitHub in case you are interested in playing with the code. I would love to hear what you have to say, get in touch if you have any comments or questions.

Tdd Mobile Development Code Structure
Tdd Mobile Development Code Structure

In the next blog post, I will show how most of the code could be placed into testable libraries, and could be easily tested from your IDE (VS or Xamarin Studio), without the need to run an emulator/simulator.

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 }}