Test-driven development, or TDD, is an iterative way to create software by making many small changes backed by tests.

In this chapter, you'll learn more about the TDD Cycle. It has four steps and is also called the Red-Green-Refactor Cycle.

The goal of this chapter is to give you a feel for how Xcode testing works by creating a test target with a few tests. You'll do this while learning the key concepts of TDD.

This chapter covers how to use the XCTAssert functions. These are the primary actors of the test infrastructure. Next, you'll learn how to use the host application to drive view unit testing. Then, you'll go through gathering code coverage to verify the minimum amount of testing. Finally, you'll use the test debugger to find and fix test errors.

In the previous chapters you built out the app's state based upon what the user can do with the Start button. The main part of the app relies on responding to changes as the user moves around and records steps. These actions create events outside the program's control. XCTestExpectation is the tool for testing things that happen outside the direct flow.

In this chapter you'll learn how to use mocks to test code that depends on system or external services without needing to call services: They may not be available, usable or reliable. These techniques allow you to test error conditions like a failed save and to isolate logic from SDKs like CoreMotion and HealthKit.

You'll complete a puppy-adoption app called Dog Patch throughout this section. This app connects dog lovers with kind, professional breeders to find the puppy of their dreams. A prospective owner first browses available puppy listings within the app.

This chapter will introduce how to do TDD for RESTful networking

You'll use the network client you created in the last chapter to fetch and display dogs on the ListingsViewController

You'll use TDD to create an ImageClient for handling images. You can use ImageClient anywhere you need it in the app.

Beginning TDD on an existing, “legacy” project is much different than starting TDD on a new project. Often times, the original team has long left, and the code base is not fully understood. The project has few if any unit tests, lacks documentation and is slow to build.

Before you can start making changes, you first need to understand how a system works and which classes relate to one another. This chapter will teach you about dependency maps.

It’s always safer to make a change when you have tests in place already. In the absence of existing tests, however, you may need to make changes just to be able to add tests! One of the most common reasons for this is tightly-coupled dependencies: you can’t add tests to a class because it depends on other classes that depend on other classes… View controllers especially are often victims to this issue.

You’ll continue the work from the last chapter, further breaking **MyBiz** into modules so you can reuse the login functionality. You’ll learn how to define clean boundaries in the code to create logical units. Through the use of tests, you’ll make sure the new architecture works and the app continues to function.

You won’t always have the time, or it may simply not be feasible, to break dependencies of a very large class. In this chapter, you’ll learn strategies to add functionality to an existing class while at the same time avoiding modifying it! You’ll learn two main strategies to do this: Sprouts and Decorators.