Chapter 6: Testing, Loading, and Saving Data

At the moment, we have structures to hold the information of one to-do item. A usable to-do item app has to show and manage several to-do items. In addition, when the user closes the app and opens it again, they expect the to-do items to still be there.

This means our app needs structures that can store and load information of a list of to-do items.

In this chapter, we will add a class that stores and loads a list of to-do items to and from the filesystem of the iOS device. We will use the JSON format because it is a common choice in iOS development. It has the nice benefit in that it is easily readable by humans and computers.

The chapter is structured as follows:

• Publishing changes with Combine
• Checking items
• Storing and loading ToDoItem

Technical requirements

The source code for this chapter is available here: https://github.com/PacktPublishing/Test-Driven-iOS-Development-with-Swift-Fourth-Edition/tree/main/chapter06.

Publishing changes with Combine

In today's iOS apps, communication between different parts is often implemented using the Combine framework by Apple. In Combine, data changes are published and can be subscribed to. This design pattern helps to decouple the code and make it easier to maintain.

We will use Combine in our ToDoItemStore to inform, for example, the table view controller that something changed and the user interface should be updated with the new data.

Open Project Navigator and select the ToDoTests group. Go to the iOS | Source | Unit Test Case option to create a test case class with the name ToDoItemStoreTests. Import the ToDo module (@testable import ToDo) and remove the two test method templates.

Testing asynchronous Combine code

Up to now, all the code we've tested has been synchronous code. Publishing values in Combine is asynchronous. To be able to test Combine code, we need a way to halt the test and wait until the code we want to test is executed...

Checking items

In a to-do app, the user needs to be able to mark to-do items as done. This is an important feature of a to-do app because part of the reason people use such apps is the satisfying feeling when marking a to-do as done.

So, our app also needs this feature. As the process of building this app is driven by tests, we start with a new test for this feature. But before we can add the test for this feature, we need to think about how we can assert in the test that the feature works. This means we need a way to get all the to-do items that are already done. The easiest way to differentiate the done to-do items from the ones that are still to be done is with a property in the to-do item itself. This way, we can filter all the to-do items according to the value of that property.

With this plan, we can start writing the test:

1. Add the following method to ToDoItemStoreTests.swift:

   // ToDoItemStoreTests.swift
   func test_check_shouldPublishChangeInDoneItems()
    throws ...

Storing and loading ToDoItems

To test storing and loading to-do items, we first need to create an instance of the ToDoItemStore class, add a to-do item, destroy that store instance, and create a new one. When we add a to-do item in the first instance, all items should be stored in the filesystem. When creating the second instance, the stored items should be loaded again from the filesystem. This means when we find the item we added in the first instance after we created the second instance, storing and loading works.

Implementing storing and loading

It is essential that the test controls the environment needed for itself. This means for storing and loading to-do items, the test needs to control where the items are stored. For example, if we used Core Data to persist the to-do items, the test would be responsible for setting up a fake Core Data store just used for the test. In our app, we will store the to-do items in a JSON file. So, the test needs to control where the JSON file...

Summary

In this chapter, we have explored how to test Combine code. To make the tests easier to understand, we introduced a helper method and improved its failure message. We figured out how to make an Equatable type and how this can help in unit tests. Finally, we learned how to test storing and loading a JSON file to and from the filesystem of the iOS device.

With these skills, you should be able to write tests for a variety of different model scenarios.

In the next chapter, we will start building the user interface. We will start with the list of to-do items.

Exercises

1. Remove the expectation from the tests that test Combine code and check whether they fail.
2. Think about what needs to be done to check whether the stored file is indeed in JSON format. Do you think such a test is of any use?