Chapter 2: Understanding Test-Driven Development

Now that we have seen what unit tests are and how they can help in development, we are going to learn about test-driven development (TDD).

After giving you some insights into the origin and objective of TDD, we will move ahead and have a look at the benefits and drawbacks of it. By the end of the chapter, you will have a clear idea about the relevance of TDD and what should be or can be tested using it.

These are the main topics that we will cover in the chapter:

• The origin of TDD
• The TDD workflow
• Advantages of TDD
• Disadvantages of TDD
• What to test

The origin of TDD

In 1996, Kent Beck, Ward Cunningham, and Ron Jeffries introduced a new software development methodology called Extreme Programming while they were working on the project Comprehensive Compensation System at Chrysler. The word Extreme indicates that the concepts behind Extreme Programming are totally different from the concepts used in software development back then. For many people, these concepts sound extreme even today.

The methodology is based on 12 rules or practices. One of the rules states that developers have to write unit tests and all parts of the software have to be thoroughly tested. All tests have to pass before the software (or a new feature) can be released to customers. The tests should be written before the production code that they test.

This so-called test-first programming led to TDD. As the name suggests, in TDD, tests drive the development. This means that the developer writes code only because there is a test...

The TDD workflow – red, green, refactor

The normal workflow of TDD comprises three steps – red, green, refactor. The following sections describe these steps in detail.

Red

You start by writing a failing test. It needs to test a required feature of the software product that is not already implemented or an edge case that you want to make sure is covered. The name red comes from the way most IDEs indicate a failing test. Xcode uses a red diamond with a white x on it as shown in the following figure:

Figure 2.1 – Xcode marks a failing test with a white cross in a red diamond

It is very important that the test you write in this step initially fails. Otherwise, you can't ensure that the test works and really tests the feature that you want to implement. It could be that you have written a test that always passes and is, therefore, useless. Or, it is possible that the feature is already implemented. Either way,...

The advantages of TDD

TDD comes with advantages and disadvantages. These are the main advantages:

• You only write code that is needed: You should stop writing production code when all your tests pass and you can't think of another test to write. If your project needs another feature, you need a test to drive the implementation of that feature. The code you write is the simplest code possible. So, all the code ending up in the product is actually needed to implement the features.
• More modular design: In TDD, you concentrate on one microfeature at a time. And as you write the test first, the code automatically becomes easy to test. Code that is easy to test has a clear interface. This results in a modular design for your app.
• Easier to maintain: As the different parts of your app are decoupled from each other and have clear interfaces, the code becomes easier to maintain. You can exchange the implementation of a microfeature with a better implementation without affecting...

The disadvantages of TDD

Just like everything else in the world, TDD has some disadvantages. The main ones are listed here:

• No silver bullet: Tests help to find bugs, but they can't find all bugs that you introduce in the test code and implementation code. If you haven't understood the problem you need to solve, writing tests most probably won't help.
• It seems slower at the beginning: When you start TDD, you will get the feeling that it takes longer to make easy implementations. You need to think about the interfaces, write the test code, and run the tests before you can finally start writing the code.
• All the members of a team need to do it: As TDD influences the design of code, it is recommended that either all the members of a team use TDD or no one at all. In addition to this, it's sometimes difficult to justify TDD to management because they often have the feeling that the implementation of new features takes longer if developers write code...

What to test

What should be tested? When using TDD and following its ideology, the answer is easy – everything. You only write production code because there is a failing test.

In practice, it's not that easy. For example, should the position and color of a button be tested? Should the view hierarchy be tested? Probably not; the color and exact position of the button is not important for the functioning of an app. In the early stages of development, these kinds of things tend to change. With Auto Layout, different screen sizes, and different localizations of apps, the exact position of buttons and labels depends on many parameters.

In general, you should test the features that make the app useful for a user and those that need to work. Users don't care whether the button is exactly 20 points from the rightmost edge of the screen. Users seek apps that are easy to understand and a joy to use.

In addition to this, you should not test the whole app at once using...

Summary

In this chapter, we dipped our toes into the new waters of TDD in general. The chapter showed the workflow of TDD – red, green, refactor – which we will use throughout this book to build an app. In addition, we have seen what the advantages and the disadvantages of TDD are.

In the following chapter, we will explore how TDD works in Xcode, the tool most of us use to build iOS apps.