When you start testing, it's often hard to decide what logic you want to test and what logic you won't test. Reasons for this could vary from certain logic being too trivial, too hard, or just not important enough to test.

The above implies that you don't have to test absolutely everything in your application and that's true. Certain pieces of code are really too trivial to write a test for. Or sometimes a certain piece of code only calls out to another piece of code that's part of UIKit or another iOS framework. Determining what to test is important, and the longer you wait with deciding whether you're going to test a certain piece of logic, the harder it might become to write tests for it.

A simple rule of thumb is that you don't need to test Apple's frameworks. It's safe to assume that Apple makes sure that any code they ship is tested and if it contains bugs, there's not much you can do to fix it. And you don't want your own tests to fail where Apple's tests should have.

What you should at least test is the call-site of your methods, structs, and classes. The call-site can be defined here as the methods that other objects use to perform tasks. It's actually good practice to make anything that's not on the call-site of your objects private, meaning that outside code can't access that part of the code. We'll look more into that later when we refactor code to be more testable.

You should also test code that you might deem too trivial to write tests for. These parts of your code are likely to receive the "too trivial" approach in other aspects of the process as well. This leads to you and your coworkers paying less and less attention to this trivial piece of code and before you know it, a bug is introduced that you might not catch until your app is in the App Store. Writing trivial tests for trivial code costs very little time and saves you from minor oversights leading to large complications.

So, to sum up some simple guidelines that you might want to follow when you're writing tests:

Once you've determined what you're going to test, it's time to start writing the actual tests. However, if you've heard about testing before, you might have heard of terms like integration tests, unit tests, sanity tests, and a couple of others. The next segment will focus on a couple of the most important and well-known types of testing.

Whenever you're writing tests, it's often a good idea to ask yourself what type of test your writing. The type of testing you want to do will typically guide you toward the way your test should be structured and scoped. Having tests that are well-scoped, structured, and focused will ensure that you're building a stable test suite that properly tests your code without unintended side effects that influence the quality of your tests.

Assumptions are a huge risk when you're testing. Any time you assume anything about the environment you're testing in, your test is not reliable. If you're just getting into writing tests, it's tempting to make assumptions like: I'm testing on the simulator and my test user is always logged in so my tests can be written under the assumption that a logged in user exists. This assumption makes a lot of sense to a lot of people, but what if something happened that made the user log out? Like a test that makes sure your user can log out, which would leave the simulator without a logged in user.

When this happens, a lot of your tests will fail due to assumptions that were made about the test environment. More importantly, these tests might fail even if the code they're testing works flawlessly.

As mentioned before, tests should test a single thing in your app. They should rely on as little outside code as possible and they should be properly focused. A common pattern that people use to structure their tests and improve reliability is the 3-As or AAA approach. The name of this pattern is short for Arrange, Act, and Assert. The following is an explanation for each of the As.

To make our code more testable, we'll create a special helper that can load questions for our view controller. The helper will go to the network and fetch the questions. After doing this, a callback is used to inform the caller about the loaded questions. Because we already know that we're going to be testing this code, we'll need to think of a way to make sure that the helper works with both an offline and an online implementation.

Our tests should rely on as little outside factors as possible, so removing the networking layer from this test would be great. This means that we're going to need to split our helper up in two parts: the actual helper and a fetcher. The fetcher will implement a protocol that defines the interface that a question fetcher must have which will allow us to inject either an online or offline fetcher into the helper.

If this seems a little bit abstract and confusing to you, that's okay. We're going to slowly work our way to the nicely abstracted, testable implementation that we want to end up with. First, let's create the helper struct. Add a new Swift file named QuestionsLoader.swift and add the following implementation to it:

struct QuestionsLoader {
  typealias QuestionsLoadedCallback = (JSON) -> Void
  func loadQuestions(callback: @escaping QuestionsLoadedCallback) {
    guard let url = URL(string: "http://questions.movietrivia.json")
      else { return }
    URLSession.shared.dataTask(with: url) { data, response, error in
      guard let data = data,
        let jsonObject = try? JSONSerialization.jsonObject(with: data, options:
            []),
        let json = jsonObject as? JSON
        else { return }
      callback(json)
    }
  }
}

This struct defines a method to load questions with a callback. This is already nice and a lot more testable than before. We can now isolate the question loader and test it separated from the rest of our app. A test for the helper in its current state would look like the test shown in the following code:

func testLoadQuestions() {
 let questionsLoader = QuestionsLoader()
 let questionsLoadedExpectation = expectation(description: "Expected the
     questions to be loaded")
     questionsLoader.loadQuestions { _ in
       questionsLoadedExpectation.fulfill()
     }
     waitForExpectations(timeout: 5, handler: nil)
}

First, an instance of the QuestionsLoader is created. Next, we create an expectation. An expectation is used when you expect something to eventually happen. In our case, we're loading the trivia questions asynchronously. This means that we can't expect the questions to be loaded by the time our test method is finished executing. The callback that's called when the questions are loaded has a single purpose in our tests: it must fulfill the expectation.

So after we call loadQuestions(callback:), we tell XCTest to wait for our expectation to fulfill for 5 seconds. If we don't fulfill the expectation within this time window, the test fails.

You should be able to see all of the A's that you read about earlier. The first A, arrange, is where we create the loader and set up the expectation. The second A, act, is when we call loadQuestions(callback:) and tell XCTest to wait for any unfulfilled expectations. The final A, assert, is inside of the callback. We're currently not validating anything inside of the callback, but we'll get to that later.

One issue that we still have with the loader is the reliance on an active connection to the Internet. We also assume that the server we're calling is up and that the data it returns is valid. These are all assumptions that influence the reliability of our test. If we don't have an Internet connection or if the server is down, our test fails even though our code might be valid. That is not an ideal situation to find yourself in.

We can improve this by utilizing some Protocol-Oriented Programming and the dependency injection pattern. This means that we'll create a protocol that defines the public API for a networking layer. Then we'll implement a networking struct in the main project that conforms to the protocol and we'll create a property on the QuestionsLoader that holds anything that implements the networking logic. We'll also add a struct in our test target that implements the networking protocol.

By setting the test up like this, we can take the entire networking logic out of the equation and arrange our test in such a way that the networking doesn't matter. Our mock networking layer will respond with valid, reliable responses that we can test.

It's common practice to mock API responses when you're testing. In this segment, we're going to implement the mock API that was described before in order to improve the quality and reliability of our test. First, let's define our protocol. Create a new file in the app target and name it TriviaAPIProviding:

typealias QuestionsLoadedCallback = (JSON) -> Void
protocol TriviaAPIProviding {
    func loadTriviaQuestions(callback: @escaping QuestionsLoadedCallback)
}

The protocol only requires a single method right now. If you want to expand this app later, everything related to the Trivia API must be added to the protocol in order to make sure that you can create both an online version for your app and an offline version for your tests.

Next, create a file named TriviaAPI and add the following implementation to it:

import Foundation
struct TriviaAPI: TriviaAPIProviding {
    func loadTriviaQuestions(callback: @escaping QuestionsLoadedCallback) {
        guard let url = URL(string: "http://quesions.movietrivia.json")
           else { return }
    URLSession.shared.dataTask(with: url) { data, response, error in
           guard let data = data,
             let jsonObject = try? JSONSerialization.jsonObject(with: data, options:
                 []),
             let json = jsonObject as? JSON
             else { return }
           callback(json)
        }
     }
  }

Lastly, update the QuestionsLoader struct with the following implementation:

struct QuestionsLoader {   
    let apiProvider: TriviaAPIProviding
    func loadQuestions(callback: @escaping QuestionsLoadedCallback) {
        apiProvider.loadTriviaQuestions(callback: callback)
    }
}

The questions loader now has an apiProvider that it uses to load questions. Currently, it simply delegates any load call over to its API provider but we'll update this code soon to make sure that we convert the raw JSON data that the API returns to us, to question models. First, update our view controller and we'll implement the mock API struct in our test so we can create our first passing test.

Update the viewDidAppear(_:) method of the LoadTriviaViewController as shown in the following code. This implementation uses the loader struct instead of directly loading the data inside of the view controller:

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    let apiProvider = TriviaAPI()
    let questionsLoader = QuestionsLoader(apiProvider: apiProvider)
    questionsLoader.loadQuestions { [weak self] json in
        self?.triviaJSON = json
        self?.performSegue(withIdentifier: "TriviaLoadedSegue", sender: self)
    }
}

The preceding code is not only more testable, it's also a lot cleaner. Next up, is creating the mock API inside of our test target.

First of all, the JSON file in the app target should be removed from the app target and added to the test target. Drag it into the correct folder and make sure to update the Target Membership so the JSON file is only available in the test target. Now add a new .swift file named MockTriviaAPI to the test target and add the following code to it:

import Foundation
@testable import MovieTrivia

struct MockTriviaAPI: TriviaAPIProviding {
    func loadTriviaQuestions(callback: @escaping QuestionsLoadedCallback) {
        
        guard let filename = Bundle(for: LoadQuestionsTest.self).path(forResource: "TriviaQuestions", ofType: "json"),
            let triviaString = try? String(contentsOfFile: filename),
            let triviaData = triviaString.data(using: .utf8),
            let jsonObject = try? JSONSerialization.jsonObject(with: triviaData, options: []),
            let triviaJSON = jsonObject as? JSON
            else { return }
        
        callback(triviaJSON)
    }
}

This code fetches the locally stored JSON file from the test bundle. We use one of the test classes as the class that we load the bundle for. This is not the absolute best way to retrieve a bundle, because we rely on an external factor being in our test target. However, we can't use structs to look up the current bundle and if we remove the class we rely on, we'll get a compile time error which is good enough for now. Once the file is loaded, we call the callback and we have successfully handled the request.

Mocking APIs is often done with external frameworks. This is mostly because not all APIs are as straightforward as the ones we've just mocked. A lot of apps have way more complex interactions than we've just tested. The main ideas behind your architecture would remain the same, regardless of the application complexity. Protocols can help you to define a common interface for certain objects. Combining this with dependency injection like we just did for the QuestionsLoader helps to isolate the pieces of your code that you're testing, and it enables you to switch out pieces of code to make sure that you don't rely on external factors if you don't have to.

So far, our test is not particularly useful. We only test if the QuestionsLoader passes our request on to the TriviaAPIProviding object and if the callbacks are called as expected. Even though this technically qualifies as a test, wouldn't it be better if we'd test whether we can covert the JSON from the API into question objects that our app can display? And when doing so, wouldn't it be nice if we would be able to do so by creating instances of a model class instead of JSON?

Testing whether our QuestionsLoader can convert JSON into a Question model is a test that's a lot more interesting than solely testing whether the callback is called. We're now confronted with the question of whether we should add a new test, or modify the existing test. If we create a new test, we're saying that we want to test whether the callback is called and we also want to test whether the loader converted the JSON response to valid models.

If we choose to modify the existing test, we're essentially saying that we assume that the callback will be called. It's been established before that assumptions are bad and we shouldn't make them. But testing if the callback is called and testing whether the callback is called with the correct information could be considered testing the same thing twice. If the callback isn't called, it also won't be called with the correct information.

We'll write a single test with one expectation and multiple assertions. Doing this will make sure that we can fulfil our expectation of the callback being called and at the same time we can use assertions to ensure that the data that's passed to the callback is valid and correct. Using the QuestionsLoader to create instances of a model rather than using it like we do now has the added benefit of improving our app's code as well.

Right now, the app uses raw JSON to display questions. If the JSON changes, we'll need to update our view controller. If our app grows, this process would become more painful because we'd have to search in multiple view controllers. The more manual labor we have to perform in that kind of situation, the bigger the chance that we forget or overlook something.

Adding a question model involves quite a lot of refactoring. First, we'll need to define the Question model. Create a new Swift file named Question and add the following implementation to it:

import Foundation

struct Question {
    
    let title: String
    let answerA: String
    let answerB: String
    let answerC: String
    let correctAnswer: Int
    
    init?(json: JSON) {
        guard let title = json["title"] as? String,
            let answerA = json["answer_a"] as? String,
            let answerB = json["answer_b"] as? String,
            let answerC = json["answer_c"] as? String,
            let correctAnswer = json["correct_answer"] as? Int
            else { return nil }
        
        self.title = title
        self.answerA = answerA
        self.answerB = answerB
        self.answerC = answerC
        self.correctAnswer = correctAnswer
    }
}

We're using a failable initializer for this model. This allows us to stop initialization whenever we encounter invalid or incomplete JSON. This approach is really good because if we handle our optional Questions correctly, our app won't crash if we pass invalid JSON around. The rest of the code in this struct is straightforward. We extract data from the JSON and we set it as properties on the struct.

Once we've added the model, we need to make a minor adjustment to the typealias that was created for the callbacks we've used so far. Change the QuestionsLoadedCallback typealias in the TriviaApiLoading protocol file as shown here:

typealias QuestionsFetchedCallback = (JSON) -> Void

Make sure to also update the object type in the loadTriviaQuestions(callback:) function for the protocol and both implementers of the protocol. Next, rename the triviaJSON property on LoadTriviaViewController to the following.

var questionsArray: [Question]?

Make sure to replace all usage of triviaJSON to the new variable. Also, make sure to change the following line in prepare(for:sender:):

questionViewController.triviaJSON = triviaJSON

Change this line to:

questionViewController.questionsArray = questionsArray

In QuestionViewController, change the type of questionsArray to [Question] and remove the triviaJSON property. At this point, you can clear all of the JSON-related code from the guards. You should be able to do this on your own since the compiler should guide you with errors. If you get stuck, look at the finished project in the Git repository.

Lastly, we must update the QuestionsLoader struct so it converts JSON data into Question models. Replace the current implementation as shown in the following code. Most of the changes have been highlighted:

import Foundation
typealias QuestionsLoadedCallback = ([Question]) -> Void
struct QuestionsLoader {
    let apiProvider: TriviaAPIProviding
    func loadQuestions(callback: @escaping QuestionsLoadedCallback) {
        apiProvider.loadTriviaQuestions { json in
            guard let jsonQuestions = json["questions"] as? [JSON]
                else { return }
            let questions = jsonQuestions.map { jsonQuestion in
                return Question(json: jsonQuestion)
            }.flatMap { $0 }
            callback(questions)
       }
    }
 }

Note that we use both map and flatMap to create the array of questions. Since the initializer for Question can fail, map gives us an array of [Question?]. Calling flatMap on this array will unwrap all of the optionals, filtering out any nil values and returning an array of [Question] which is exactly what we need for the callback.

By now, you should be able to run the tests and they should pass. To run your tests, click the Product menu item and select Test . Alternatively, press cmd + U to run your tests. The tests run fine but currently we haven't made sure that all of our questions in the JSON data have been converted to Question models. To make sure this worked, we'll load the JSON file in our test case, count the number of questions in the JSON file, and assert that it matches the number of questions in the callback.

Update the testLoadQuestions() method as shown in the following code. The lines that have changed are highlighted:

func testLoadQuestions() {
    let apiProvider = MockTriviaAPI()
    let questionsLoader = QuestionsLoader(apiProvider: apiProvider)
    let questionsLoadedExpectation = expectation(description: "Expected the questions to be loaded")
    questionsLoader.loadQuestions { questions in
        guard let filename = Bundle(for: LoadQuestionsTest.self).path(forResource: 
           "TriviaQuestions", ofType: "json"),
            let triviaString = try? String(contentsOfFile: filename),
            let triviaData = triviaString.data(using: .utf8),
            let jsonObject = try? JSONSerialization.jsonObject(with: triviaData,
                                                   options: []),
            let triviaJSON = jsonObject as? JSON,
            let jsonQuestions = triviaJSON["questions"] as? [JSON]
            else { return }
        
        XCTAssert(questions.count > 0, "More than 0 questions should be passed to the 
          callback")
        XCTAssert(jsonQuestions.count == questions.count, "Number of questions in json 
          must match the number of questions in the callback.")
        
        questionsLoadedExpectation.fulfill()
    }
    
    waitForExpectations(timeout: 5, handler: nil)
}

We use the same code as the code that's used in the fake API to load the JSON file. Once the JSON is loaded, we use XCTAssert to make sure that more than zero questions were passed by the callback and that the amount of questions in the JSON file matches the number of questions that were loaded.

XCTAssert takes a Boolean expression and a description. If the assertion fails, the description is shown. Adding good descriptions will help you to easily figure out which assertion in your test has made your test fail.

This new test method is a small addition to our test that has huge consequences. By improving our test, we have improved the quality of our app because we are now sure that our questions loader correctly transforms JSON into model objects. By adding model objects, we have improved the code in our view controllers because instead of reading raw JSON, we're reading properties from a model. And the final improvement that this modification gives us is that our view controllers are a lot cleaner.

One more metric that has improved by refactoring our code is the amount of code that is covered by our tests. We can measure this metric with Xcode's built in code coverage tracking. We'll look at how to use this tool next.