Open ToDoItemTests.swift and add the following import expression right below import XCTest:

@testable import ToDo 

This is needed in order to be able to test the ToDo module. The @testable keyword makes the internal methods of the ToDo module accessible to the test case.

Remove the two template test methods, testExample() and testPerformanceExample().

The title of a to-do item is required. Let's write a test to ensure that an initializer exists that will take a title string. Add the following test method to the end of the test case (but within the ToDoItemTests class):

func test_Init_TakesTitle() { 
  ToDoItem(title: "Foo") 
} 

The static analyzer built into Xcode will complain about Use of unresolved identifier 'ToDoItem':

We cannot compile this code because Xcode cannot find the ToDoItem identifier. Remember that a non-compiling test is a failing test; and as soon as we have a failing test, we need to write implementation code to make the test pass.

To add a file for the implementation code, first, click on the ToDo group in the Project Navigator. Otherwise, the added file will be put into the test group. Go to File | New | File..., navigate to the iOS | Source | Swift File template, and click on Next. In the Save As field, add the name ToDoItem.swift; make sure that the file is added to the ToDo target and not to the ToDoTests target, and click on Create.

Open ToDoItem.swift in the editor, and add the following code:

struct ToDoItem { 
} 

This code is a complete implementation of a struct named ToDoItem. So, Xcode should now be able to find the ToDoItem identifier. Run the test by either going to Product | Test or using the command + U shortcut. The code does not compile because there is an argument passed to a call that takes no arguments. This means that at this stage, we could initialize an instance of ToDoItem like this:

let item = ToDoItem() 

But we want to have an initializer that takes a title. We need to add a property, named title, of type String to store the title:

struct ToDoItem { 
  let title: String 
} 

Run the test again. It will pass. We have implemented the first micro feature of our to-do app using TDD. And it wasn't even hard. For the rest of the book, we will do this over and over again until the app is finished. But we first need to check whether there is anything to refactor in the existing test and implementation code. The tests and code are clean and simple. There is nothing to refactor yet.

There are, however, a few things to note about the test. First, Xcode shows a Result of 'ToDoItem' initializer is unused warning. To make this warning go away, assign the result of the initializer to an underscore _ = ToDoItem(title: "Foo"). This tells Xcode that we know what we are doing. We want to call the initializer of ToDoItem, but we do not care about its return value.

Second, there is no XCTAssert function call in the test. To add an assert, we could rewrite the test like this:

func test_Init_TakesTitle() { 
  let item = ToDoItem(title: "Foo") 
  XCTAssertNotNil(item, "item should not be nil") 
} 

But in Swift, a non-failable initializer cannot return nil. It always returns a valid instance. This means that the XCTAssertNotNil() method is useless. We do not need it to ensure that we have written enough code to implement the tested micro feature. Following the rules of TDD mentioned in Chapter 1, Your First Unit Tests, we are not allowed to write this code. It is not needed to drive the development, and it does not make the code better.

Before we proceed with the next few tests, let's set up the editor in a way that makes the TDD workflow easier and faster. Open ToDoItemTests.swift in the editor. Open Project Navigator, and hold down the Option key while clicking on ToDoItem.swift in the navigator to open it in the Assistant Editor. Depending on the size of your screen and your preferences, you might prefer to hide the navigator again. With this setup, you have the tests and the code side by side, and switching from test to code and vice versa takes no time. In addition to this, as the relevant test is visible while you write the code, it can guide the implementation.