Reader small image

You're reading from  Test-Driven iOS Development with Swift - Fourth Edition

Product typeBook
Published inApr 2022
PublisherPackt
ISBN-139781803232485
Edition4th Edition
Right arrow
Author (1)
Dr. Dominik Hauser
Dr. Dominik Hauser
author image
Dr. Dominik Hauser

Dr. Dominik Hauser is an iOS developer working for a small company in western Germany. In over 11 years as an iOS developer, he has worked on many different apps, both large and small. In his spare time, Dominik builds small (often silly) apps and explores how he can become a better iOS developer. He talks at conferences, writes books, and is active in the iOS community in general. His most successful open source component (in terms of stars) is a pull-to-refresh control for a table view that consists of an actual SpriteKit game. Before Dominik became an iOS developer, he was a physicist, researching the most powerful photon sources within our galaxy.
Read more about Dr. Dominik Hauser

Right arrow

Chapter 5: Building a Structure for ToDo Items

iOS apps are often developed using a design pattern called Model-View-Controller (MVC). In this pattern, each class, struct, or enum is either a model object, view, or controller. Model objects are responsible for storing data. They should be independent of the kind of presentation provided by the UI. For example, it should be possible to use the same model object for an iOS app and a command-line tool on macOS.

View objects present the data. They are responsible for making the objects visible (or hearable, in the case of a VoiceOver-enabled app) for the user. Views are special for the device that the app is executed on. In the case of a cross-platform app, view objects cannot be shared. Each platform needs an implementation of a view layer.

Controller objects communicate between the model and view objects. They are responsible for making the model objects presentable.

We will use MVC for our to-do app because it is one of the...

Technical requirements

All the code for this chapter can be found (in its complete form) here: https://github.com/PacktPublishing/Test-Driven-iOS-Development-with-Swift-Fourth-Edition/tree/main/chapter05.

Implementing the ToDoItem struct

To be useful, to-do items need a minimal set of information. In this section, we will create a structure to hold this information while using tests to guide their development.

A to-do app needs a model class/struct to store information for to-do items:

  1. We will start by adding a new test case to the unit test target. Open the to-do project that we created in the Getting started with Xcode section of Chapter 4, The App We Are Going to Build, and select the ToDoTests group.
  2. Go to File | New | File..., navigate to iOS | Source | Unit Test Case Class, and click on Next. Put in the name ToDoItemTests, make it a subclass of XCTestCase, select Swift as the language, and click on Next.
  3. In the next window, click on Create.
  4. Now, delete the ToDoTests.swift template test case.

Adding a title property

A to-do item needs a title. Follow these steps to add one to our ToDoItem struct:

  1. Open ToDoItemTests.swift and add the following...

Implementing the Location struct

In the previous section, we added a struct to hold information about the location. We will now add tests to make sure that Location has the required properties and initializer.

These tests could be added to ToDoItemTests, but they are easier to maintain when the test classes mirror the implementation classes/structs. So, we need a new test case class.

Open the Project navigator, select the ToDoTests group, and add a unit test case class called LocationTests. Make sure that you go to iOS | Source | Unit Test Case Class since we want to test the iOS code, and Xcode sometimes navigates to OS X | Source.

Set up the editor to show LocationTests.swift on the left-hand side and Location.swift in the Assistant Editor on the right-hand side. In the test class, add @testable import ToDo and remove the testExample() and testPerformanceExample() template tests.

Adding a coordinate property

The location of a to-do item will be used in the app to show...

Summary

In this chapter, we created a structure to hold information for to-do items using TDD. We learned that TDD means switching between test code and production code all the time. In addition, we realized that we should use the assert method with the accuracy parameter when we need to compare floating-point numbers. What you learned in this chapter will help you write better and more robust unit tests.

In the next chapter, we will build a structure to manage to-do items. They need to be stored somewhere and we need to have a way to add and check off to-do items.

Exercises

  1. Try to write a test using XCTAssertEqual(_:_:) that fails, even if the values are equal, because of problems in comparing floating points. Hint: You often get this problem when using simple math functions such as addition and multiplication.
  2. Make ToDoItem conform to Equatable and rewrite the assertions to take advantage of that conformance.
lock icon
The rest of the chapter is locked
You have been reading a chapter from
Test-Driven iOS Development with Swift - Fourth Edition
Published in: Apr 2022Publisher: PacktISBN-13: 9781803232485
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime

Author (1)

author image
Dr. Dominik Hauser

Dr. Dominik Hauser is an iOS developer working for a small company in western Germany. In over 11 years as an iOS developer, he has worked on many different apps, both large and small. In his spare time, Dominik builds small (often silly) apps and explores how he can become a better iOS developer. He talks at conferences, writes books, and is active in the iOS community in general. His most successful open source component (in terms of stars) is a pull-to-refresh control for a table view that consists of an actual SpriteKit game. Before Dominik became an iOS developer, he was a physicist, researching the most powerful photon sources within our galaxy.
Read more about Dr. Dominik Hauser