Chapter 4: The App We Are Going to Build

In the previous chapters, you learned how to write unit tests and saw an easy example of test-driven development (TDD). When starting TDD, writing unit tests is easy for most people. The hard part is transferring knowledge from writing tests to driving development. What can be assumed? What should be done before we write 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 lay out 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...

Technical requirements

All the code in this chapter is uploaded (in complete form) here:

https://github.com/PacktPublishing/Test-Driven-iOS-Development-with-Swift-Fourth-Edition/tree/main/chapter04

A list of to-do items

When starting the app (the one we are going to build), the user sees a list of to-do items on the screen of their iOS device. The items in the list consist of a title, an optional location, and the due date. New items can be added to the list by using an add (+) button, which is shown in the navigation bar of the view. The task list view will look like this:

Figure 4.1 – A list of to-do items

As a user, I have the following requirements:

• I want to see a list of to-do items when I open the app.
• I want to add to-do items to the list.

In a to-do list app, the user will obviously need to be able to check off items when they are finished. The checked items are shown below the unchecked items, and it is possible to uncheck them again. The app uses the Delete button in the UI of the table view to check and uncheck items. Checked items will be put at the end of the list in a section with the Done header. The UI for the...

A view for the details of a to-do item

The task detail view shows all the information that's stored for a to-do item. The information consists of a title, due date, location (name and address), and a description. If an address is given, a map with an address is shown. The detail view also allows checking off the item as done. The Details view looks like this:

Figure 4.3 – The view for the details of a to-do item

As a user, I have the following requirements:

• I have tapped a to-do item in the list and I want to see its details.
• I want to check a to-do item from its details view.

You need to be able to add to-do items to the list. The next section shows what this input view will look like.

A view to add to-do items

When the user selects the add (+) button in the list view, the task input view is shown. The user can add information for the task. Only the title is required. The Save button can only be selected when a title is given. It is not possible to add a task that is already on the list. The Cancel button dismisses the view. The task input view will look like this:

Figure 4.4 – The view to add a to-do item to the list

As a user, I have the following requirements:

• Given that I tapped the add (+) button in the item list, I want to see a form to put in the details (title, optional date, optional location name, optional address, and optional description) of a to-do item.
• I want to add a to-do item to the list of to-do items by tapping on the Save button.

We will not implement the editing and deletion of tasks, but when you have worked through this book completely, it will be easy for you to add this feature yourself...

The structure of the app

Before we start to implement the different views of our to-do app, we need to think about the structure of our app. The app is quite simple on purpose to help keep the focus on the main topic of this book: building an app using TDD.

The table view controller, the delegate, and the data source

In iOS apps, data is often presented using a table view. Table views are highly optimized for performance; they are easy to use and implement. We will use a table view for the list of to-do items.

A table view is usually represented by UITableViewController, which is also the data source and delegate for the table view. This often leads to a massive table view controller, because it is doing too much: presenting the view, navigating to other view controllers, and managing the presentation of the data in the table view.

To reduce the responsibility of the table view controller a bit, we will use the coordinator pattern. This way, a coordinator is responsible...

Getting started in Xcode

Now, let's start our journey by creating a project that we will implement using TDD. Proceed as follows:

1. Open Xcode and create a new iOS project using the App template.
2. In the Options window, add ToDo as the product name, select the Storyboard interface and Swift as the language, and check the box next to Include Tests. Let the Use Core Data box stay unchecked.

Xcode creates a small iOS project with three targets: one for the implementation code, one for the unit, and one for the UI tests. The template contains code that presents a single view on the screen.

3. To take a look at how the app target and test target fit together, select the project in the project navigator and then select the ToDoTests target. In the General tab, you'll find a setting for the Host Application that the test target should be able to test. It looks like this:

Figure 4.5 – General settings for the test target

Xcode...

Summary

In this chapter, we took a look at the app that we are going to build throughout the course of this book. We took a look at how the screens of the app will look when we are finished with it. We created a project that we will use later on and learned about Xcode behaviors.

In the next chapter, we will develop the data model of the app using TDD. We will use structs for the model wherever we can because models are best represented in Swift by value types.

Exercises

1. Replicate the mock-up screens using a storyboard in Xcode.
2. Change the behaviors such that you can figure out if a test failed or if all tests passed without looking at the screen.