In the previous chapter, you learned how to write unit tests and saw an easy example of TDD. When starting TDD, writing unit tests is easy for most people. The hard part is to transfer knowledge from writing test to driving development. What can be assumed? What should be done before one writes the first test? What should be tested to end up with a complete app?

As a developer, you are used to thinking in terms of code. When you see a feature on the requirement list for an app, your brain already starts to layout the code for this feature. For recurring problems in iOS development (such as building table views), you most probably have already developed your own best practices.

In TDD, you should not think about the code while working on the test. The tests have to describe what the unit under test should do and not how it should do it. It should be possible to change the implementation without breaking the tests. Thinking like this is the hard part about TDD. You'll need a lot of practice before this becomes natural.

To practice this approach of development, we will develop a simple to-do list app in the remainder of this book. It is, on purpose, a boring and easy app. We want to concentrate on the TDD workflow, not complex implementations. An interesting app would distract from what is important in this book--how to perform TDD.

This chapter introduces the app we are going to build and shows the views that the finished app will have.

We will cover the following topics in this chapter:

• The task list view
• The task detail view
• The task input view
• The structure of an app
• Getting started with Xcode
• Setting up useful Xcode behaviors for testing