Why? What? How?

7 min readApr 28, 2016

Introduction

Unfortunately, it isn't common to see the test code in a mobile project. Because many people don't know the importance of testing, which is or how to do it.

According to with the teacher of MIT Rob Miller [1], testing is a little part of a more general process called validation. Look the Figure 1 for understanding:

Why need to create tests?

10 reasons about why the application needs tests:

1. Integration, you can integrate your tests code with a tool to validate the tests automatically by git flow for example.
2. Reduce bugs, is a good practice to verify source code, but not necessarily a truth with a reduce bugs depends on the quality of tests.
3. Security, using tests to check if your application is safety to attacks.
4. Assurance, the behavior of the application is in agreement with what the designer has created and the client need.
5. Refactor, TDD or Test Driven Development has code refactor in your step. Change the source code without a test is not a good practice.
6. Coverage, is a number that represents to the developer how many your application covered with tests but not necessarily poses a quality of your code. Because wrong test, not assurance a good source code.
7. Documentation, tests can be used as documentation of your application by the developer. The tests code shows how works the application code.
8. Clean Code, it’s normal that many codes are created with unnecessary parts and refactor is a step of a developer to clear it.
9. Best Practices, on a development flow, has as best practices a test step, an important step in software development, for example in Agile Processes [2] of Extreme Programming (XP), see Figure 2 [3]:

10. Show progress, we take a simple app for example with three layers: Presentation (UI, Controllers), Business (Service) and Data (Persistence). You can see clearly the progress with tests because you don’t need to wait for Business layer to connect with Presentation, for example, you can use Mocks, Stubs or many others strategies for your tests.

Test in Project is very costly

Accord of Tom Fischer in your article [4] about myths of test has two big myths:

First Myth, Tests saves money.

If you think that your project will be less expensive that you do not use it, you are totally wrong. Fischer created a graph to shows a difference between a project with and without tests, see Figure 3 below:

When tests included in the project, initially is most expensive than another that not used it. But Fischer shows that across of the time the application costs more money because of increased support, bug fixes, deployment, lost customers, etc. You can get a point that he called the breakeven this point at which their unit testing pays off.

In the theory it’s perfect, but in the real world, we know that a project can be later and this graph will change, see Figure 4 below:

The difference after of breakeven point between the projects that are used and not used tests is different than previous graph (Figure 3) when people of team needs to extra hours, or the velocity decreases for any reasons.

Second Myth, Tests Reduce Bugs.

Fischer defends that two services: X and Y have tests which individually pass, but when need to integrate between this services, may generate a different output that is not correct.

Figure 5 represents a simple communication between a mobile application and server API. Each part has tests, but when integrated between them, the unit tests doesn’t insurance that will work correctly.

Agile programming has test action in your process

The Manifesto for Agile was created by seventeen people [5]. Kent Beck participated it. He’s created the Extreme Programming (XP) and introduced in Agile Programming the Test Driven Development or TDD, see Figure 6:

Figure 6— Create a figure that represents an agile flow and includes TDD flow it.

Kent Beck defends that TDD is an important technique to development software with getting a high quality.

What is TDD?

TDD or Test Driven Development is a simple method to test-first on the development software. We can see the TDD flow is very comfortable with Figure 7:

The first step, you create a test, and you run it off course that will fail it because you don’t have any code for this test. Red color represents this step.
The second step, represented by green color is more simplistic that first, write code to the test pass and run. It will pass off course.
Back to the code and refactor it.

It’s simple but not common to use, but an important technique that you can use in your agile process.

Let's get the example:

I used an iOS project and XCTest framework by Apple to show the TDD process.

My test testLog_WithValidString_ReturnStringLog function tries to call the method debug of Log class with the message in parameter, but off course, that failed it, because my class Log doesn’t have the debug function, see the class Log below:

//
// Log.swift
// TDD
//
// Created by Geraldo Bastos on 4/25/16
// Copyrigh © 2016 GeraldoBastos. All rights reserved.
//import Foundationpublic class Log {
}

Now, doing the second step of TDD, we create a method to will pass the test:

//
// Log.swift
// TDD
//
// Created by Geraldo Bastos on 4/25/16
// Copyrigh © 2016 GeraldoBastos. All rights reserved.
//import Foundationpublic class Log {
     public class debug(message: String) -> String? {
         return message
     }
}

and run the test before:

Now that the test passed we need to back the source code and refactoring it:

//
// Log.swift
// TDD
//
// Created by Geraldo Bastos on 4/25/16
// Copyrigh © 2016 GeraldoBastos. All rights reserved.
//import Foundationpublic class Log {
      class public fund debug(message: String) -> String? {
          var result: String?
          let characterSet = NSCharacterSet.whitespaceAndNewlineCharacterSet()
          let trimmingValue = message.stringByTrimmingCharactersInSet(characterSet)           if trimmingValue.characters.count > 0 {
               result = "[DEBUG] - \(message)"
           }           return result
      }
}

When you finish the refactoring, you need to run the tests (better when the project has CI) to check it:

Continuous Integration

A tool that is used to agile process is Continuous Integration or CI for:

“… a fully automated and reproducible build, including testing, that runs
many times a day. This allows each developer to integrate daily, thus
reducing integration problems." (Martin Fowler and Matthew Foemmel) [6]

Grady Booch firstly used the word Continuous Integration in your book — Object-Oriented Analysis and Design with Applications (2nd edition). He defends that all devs need daily send the code to mainline, and this process was adapted to Extreme Programming, see Figure 12. But differently of Booch saw, the XP process defends that this process needs to do many times of the day.

CI is better when you used with a good repository flow, is common use GIT as a repository. Many types of flow can do it, but a most used are specific branches are: master, develop, feature branches, hotfixes and release branches. This branches and flow were presented by Vincent Driessen with your excellent article with title "A successful Git branching model" [7].

Figure 13 — Git Branching Model by Vincent Driessen

With this git flow, you can use the CI a particular branch and your team works without problem.

So, tests were created and inserted in Agile flow for many reasons: quality, security, assurance, etc. We have a TDD that was created by Kent Beck to facilitate a developer create tests, and we have a Continuous Integration tool to integrate the code with git and assurance the quality of tests and code.