In this section, you'll work on a test suite for a new app: MovieTrivia. You'll find the basic setup for this project in this book's code bundle. If you open the project, there are some view controllers, an Info.plist file, and all the other files you would normally expect to find in a project. There's also a JSON file in the project named TriviaQuestions.json. This file contains a couple of dummy questions that you can load by uncommenting a bit of code in LoadTriviaViewController.swift.

By default, LoadTriviaViewController.swift attempts to load questions from a non-existing web server. This is intentional, to demonstrate how one would normally set up a project like this. Since you don't have a web server at your disposal right now, you can swap out the dummy networking code for the JSON file to test this app.

Before you write tests or perform any optimization, you must add a test target to the project. You add a test target in the same way you added extensions before. The only difference is that you select a different type of target. When adding a test target, you should pick the iOS Unit Testing Bundle template. The following screenshot shows the correct template you should select:

After adding the target, Xcode adds a new folder to your project. If you choose the default name for the test target, it's called MovieTriviaTests. You should add all the tests you write for this project to the test target.

If you think about when you used files in multiple targets with extensions, you might expect that you would need to add all of the files you want to write tests for to both of the targets. Fortunately, this isn't the case. When you write tests, you can import the entire app as a testable target, enabling you to write tests for all of the code in the app target.

If you look inside the MovieTriviaTests folder that Xcode created when you added the unit test target, you'll find a single file called MovieTriviaTests.swift. This file contains a couple of hints about what tests should look like for your test suite. First of all, note that the test class inherits from XCTestCase. All of your test classes should inherit from this XCTestCase so they can be identified as a test.

One of the methods you'll find in the test template is the setUp() method. This method is executed before every test in the file and helps you to fulfill the first stage of the AAA pattern in testing: Arrange. You use this method to ensure that all of the preconditions for your test are met. You could make sure that your user is logged in or that your database is populated with test data. Of course, the depth of your setup in this method depends on the unit of code for which you're writing a test.

Also, note that there are two methods prefixed with test in the test class. These methods are executed as tests, and they are expected to perform the act and assert steps. The majority of work should be performed in these test methods. Do note that it's often better to have multiple short test methods rather than a single test method that tests everything. The larger the methods, the harder it will be to maintain and debug your tests.

Finally, you'll find a tearDown() method. This method is intended to give you an opportunity to clean up after yourself. When you have inserted dummy data into your database, it's often desirable to remove this data when your tests have completed. This will ensure a clean slate for the next test that runs, and it minimizes the chances that your first test accidentally influences the second test that runs. As mentioned before, tests should never depend on other tests. This means that you also don't want to pollute other tests by leaving traces of previous tests.

Note that setUp() and tearDown() should be specific to the unit you're testing. This means that you can't put all of your tests in a single class. Separating tests into several classes is a good thing. You should create a test class for every unit of code that you're testing. One test class should typically not test more than a single class or struct in your app. If you're writing an integration test, there might be more than one class involved in the test, but you should still make sure that you're only testing a single thing, which is the integration between the classes involved in the integration you're testing.

Now that you have a test suite in place, let's see how you can write tests for the existing code in the MovieTrivia app and how the app can be refactored to be tested appropriately.