This is part 2 of the blog series: How To Build An App Without Interface Builder. You can find information about this series here. In the previous post we set up the project and removed the storyboard.

In part 2 we will see sketches of the app, we will discuss the structure of the project and we will create our first tests (remember, we try to stick with Test Driven Development (TDD) for this app).


What should the app look like? I have doodled around a bit and came up with the following sketches (made using Paper by 53):

The main view of the app is going to show a list. In the list are the birthdays of friends and family ordered by time until birthday. In the cells of the list is a progress indicator which color will be selectable in the input of the birthday.

One cell will look like this:

In front of the progress indicator will be the name and the date of the birthday. The name should change color depending on the progress.

The input view should look like this:

Thats all for the sketches. You see the app is small and easy. But it's also a good foundation for extensions like a present planer or a mail composer for the birthday mail.


Usually I already have kind of a structure for apps I'm planning in my head. I also had ideas for the structure of this birthday app when I started to think about it. Most of the times I don't draw the structure. But drawing is actually a good way to make sure you haven't forgotten something and often you find better ways to do something. And it is a good reference for later in the project.

Here is the structure of this simple app.

The structure of the project is very simple. We only have two controllers and a few other classes. The birthday list will be a table view because table views are very powerful and highly optimized on iOS. More on that later in this series.

At this stage we won't need communication with a server or Core Data to store the birthdays. We will serialize the data on disk.

Test Driven Development

We will use test driven development (or test-first development or TDD) for this app. This means we will first write the tests that describe what we expect to happen and then we write the code to make the tests pass. TDD is often divided in three phases, called Red, Green, Refactor.


In the red phase you write the test for a micro feature without thinking about possible implementations. This is hard if you are new to this kind of development. As I am kind of a beginner in TDD as well I often have difficulties to not think about a special implementation. We are going to learn this together. :)


In the green phase you write the simplest code that make the test pass. It doesn't matter if the code is good or bad. It doesn't matter if you are ashamed of the code you write in this phase. It's important that you only write code that makes the test green. Don't think about other features yet. Just make this one test pass.


Now that you have proven to have some usual code you can transform it to good code. You don't have to worry about the feature anymore because you have test that makes sure that the feature survives your refactoring. Do what ever is needed to transform the code in something you aren't ashamed of anymore. But make sure the test passes after you are finished. And don't forget to refactor the test code as well when needed.

Your First Tests

What Tests Look Like?

Now let's jump head in and write the first tests. Open BirthdaysTests.swift and add the following two methods below the tearDown() method:

func testExampleThatPasses() {
  XCTAssertEqual(1+1, 4-2, "Should both be 2")

func testExampleThatFails() {
  XCTAssertEqual(1+1, 4-1, "Should both be 2")

The first is an example for a passing test and the second is an example for a failing test. Delete the other test methods, testExample() and testPerformanceExample().

To run the tests either go to Product / Test or just hit ⌘U. You should see something like this:
Screen Shot 2015-08-08 at 10.58.09

And now you can relate why the first two phases of TDD are called red and green phase. ;)

Obviously those test have nothing to do with the app we are trying to build. I have included them here in case you haven't seen a test before.

The First Real Test

Select the BirthdaysTests folder in Xcode an go to File / New / File.... Select iOS / Source / Unit Test Case Class, click Next, put in the name BirthdaysListViewControllerTests and make sure the language is set to Swift. Click Next. You are now asked where to store the file. In the lower left corner click New Folder and call it BirthdaysList. Click Create two times.

Now, delete BirthdaysTests.swift. The name is misleading because we won't put all our tests into one file. Ever!

Open BirthdaysListViewControllerTests.swift and delete the methods testExample() and testPerformanceExample(). In the file you see two other methods, setUp() and tearDown(). As the names suggest they are used to setup and tear down the test environment for each test.

Finally you are going to write a real test. First add the following line right below the import of XCTest:

@testable import Birthdays

This import exposes the classes and methods in the Birthdays module to the tests target.

At the beginning of the BirthdaysListViewControllerTests class add the property var viewController: BirthdaysListViewController!. The compiler will warn you that this class does not exists. True that. We'll fix this in a minute.

Add the following code at the end of setUp():

viewController = BirthdaysListViewController()

Add the following method to the end of the BirthdaysListViewControllerTests class:

func testViewController_HasTableView() {

Run the tests. The tests fail. In fact Xcode even refuses to compile the project because it doesn't find the class BirthdaysListViewController. This was the red phase, let's move to the green phase:

Select the Birthdays folder in Xcode, select File / New / File..., chose iOS / Source / Cocoa Touch Class, click Next, put in the name BirthdaysListViewController, make it a subclass of UITableViewController, click Next, create a folder BirthdaysList. Click Create two times.

Run the test again. All green \o/! We have just test-driven a small part of the app.

The test is not very useful at this stage. But it still has some value. Remember that in TDD there will be a lot refactoring. This test makes sure that there will always be a property called tableView. So in case we decide that the data is better presented using a collection view, we first need to change the test and make it red again.

If you enjoyed this post, then make sure you subscribe to my feed.

Part 3: A Decision