func testScoreIsComputedWhenGuessIsLowerThanTarget() {
  // given
  let guess = sut.targetValue - 5

  // when
  sut.check(guess: guess)

  // then
  XCTAssertEqual(sut.scoreRound, 95, "Score computed from guess is wrong")
}

Разница между guess и targetValue по-прежнему равна 5, поэтому результат должен быть 95.
В Breakpoint navigator добавьте Test Failure Breakpoint (точку остановки при ошибке теста). Это остановит работу теста, когда метод теста отправит утверждение об ошибке.

Запустите тест, он должен остановиться на строке XCTAssertEqual ошибкой теста.
Обратимся к sut и guess в консоли отладки:

guess равен targetValue − 5, но scoreRound равен 105, а не 95!

Дальше используйте обычный процесс отладки: установите брейкпоинт в операторе when, а также в BullsEyeGame.swift, внутри check(guess:), где создается difference. Затем снова запустите тест и перешагните через оператор let difference, чтобы проверить значение difference в приложении:

Проблема в том, что difference отрицательная, поэтому результат 100 - (−5). Чтобы исправить это, вы должны использовать абсолютное значение difference. В check(guess:) раскомментируйте правильную строку и удалите неправильную.

Удалите два брейкпоинта и снова запустите тест, чтобы убедиться, что он успешно завершен.

Использование XCTestExpectation для тестирования асинхронных операций

Теперь, когда вы знаете, как тестировать модели и отлаживать ошибки тестирования, пора перейти к тестированию асинхронного кода.

BullsEyeGame использует URLSession для получения случайного числа в качестве таргета для следующей игры. Методы URLSession асинхронны: они возвращаются сразу, но не завершают свою работу позже. Чтобы протестировать асинхронные методы, используйте XCTestExpectation, чтобы ваш тест ждал завершения асинхронной операции.

Асинхронные тесты обычно проходят медленно, поэтому вы должны держать их отдельно от более быстрых модульных тестов.

Создайте новый unit test target с именем BullsEyeSlowTests. Откройте новый тестовый класс BullsEyeSlowTests и импортируйте модуль приложения BullsEye чуть ниже существующего оператора import:

@testable import BullsEye

Все тесты в этом классе используют URLSession по умолчанию для отправки запросов, поэтому объявите sut, создайте его в setUpWithError() и освободите в tearDownWithError(). Для этого замените содержимое BullsEyeSlowTests на:

var sut: URLSession!

override func setUpWithError() throws {
  try super.setUpWithError()
  sut = URLSession(configuration: .default)
}

override func tearDownWithError() throws {
  sut = nil
  try super.tearDownWithError()
}

Затем добавьте этот асинхронный тест:

// Asynchronous test: success fast, failure slow
func testValidApiCallGetsHTTPStatusCode200() throws {
  // given
  let urlString = 
    "http://www.randomnumberapi.com/api/v1.0/random?min=0&max=100&count=1"
  let url = URL(string: urlString)!
  // 1
  let promise = expectation(description: "Status code: 200")

  // when
  let dataTask = sut.dataTask(with: url) { _, response, error in
    // then
    if let error = error {
      XCTFail("Error: \(error.localizedDescription)")
      return
    } else if let statusCode = (response as? HTTPURLResponse)?.statusCode {
      if statusCode == 200 {
        // 2
        promise.fulfill()
      } else {
        XCTFail("Status code: \(statusCode)")
      }
    }
  }
  dataTask.resume()
  // 3
  wait(for: [promise], timeout: 5)
}

Этот тест проверяет, что отправка валидного запроса возвращает код состояния 200. Большая часть кода совпадает с тем, что вы пишете в приложении + эти дополнительные строки:

1. expectation(description:): возвращает XCTestExpectation, хранящееся в promise. description описывает то, что вы ожидаете.
2. promise.fulfill(): вызовите этот код в клоужере, отвечающем за успех завершающего обработчика асинхронного метода, чтобы показать, что наши ожидания были оправданы.
3. wait(for:timeout:): тест продолжается до тех пор, пока не будут выполнены все ожидания или пока не закончится интервал timeout, в зависимости от того, что произойдет раньше.

Запустите тест. Если вы подключены к Интернету, проверка должна занять около секунды после загрузки приложения в симуляторе.

Быстрый фейл

Фейл - это больно, но он не должен длиться вечно.
Чтобы произошел сбой, просто измените URL-адрес в testValidApiCallGetsHTTPStatusCode200() на невалидный:

let url = URL(string: "http://www.randomnumberapi.com/test")!

Запустите тест. Он фейлится, но требует полный интервал timeout! Это произошло потому, что вы предполагали, что запрос всегда будет проходить, и именно здесь вы вызвали promise.fulfill(). Поскольку запрос не удался, он завершился только по истечении тайм-аута.

Можно ускорить выполнение теста, изменив предположение. Вместо того, чтобы ждать успешного выполнения запроса, дождитесь только завершения обработчика асинхронного метода. Это происходит, как только приложение получает ответ (ОК или ошибка) от сервера. Затем ваш тест может проверить, был ли запрос успешным.

Чтобы увидеть, как это работает, создайте новый тест.

Но сначала исправьте предыдущий тест, отменив изменение, которое вы внесли в url.
Затем добавьте в свой класс следующий тест:

func testApiCallCompletes() throws {
  // given
  let urlString = "http://www.randomnumberapi.com/test"
  let url = URL(string: urlString)!
  let promise = expectation(description: "Completion handler invoked")
  var statusCode: Int?
  var responseError: Error?

  // when
  let dataTask = sut.dataTask(with: url) { _, response, error in
    statusCode = (response as? HTTPURLResponse)?.statusCode
    responseError = error
    promise.fulfill()
  }
  dataTask.resume()
  wait(for: [promise], timeout: 5)

  // then
  XCTAssertNil(responseError)
  XCTAssertEqual(statusCode, 200)
}

Ключевое отличие состоит в том, что простой ввод завершающего обработчика оправдывает ожидания, и это занимает всего около секунды. Если запрос не выполняется, выражения фейлятся.

Запустите тест. Теперь это должно занять около секунды. Тест фейлится из-за фейла запроса, а не из-за превышения timeout во время выполнения теста.

Исправьте URL, а затем снова запустите тест, чтобы убедиться, что он успешно завершен.

Условный фейл

В некоторых ситуациях выполнение теста не имеет особого смысла. Например, что должно произойти, если testValidApiCallGetsHTTPStatusCode200() работает без сетевого подключения? Конечно, он не должен пройти, потому что он не получит код статуса 200. Но и он не должен провалиться, потому что ничего не проверял.
К счастью, Apple представила XCTSkip, чтобы можно было пропустить тест, если предварительные условия не выполняются. Добавьте следующую строку под объявлением sut:

let networkMonitor = NetworkMonitor.shared

NetworkMonitor обертывает NWPathMonitor, обеспечивая удобный способ проверки сетевого подключения.
В testValidApiCallGetsHTTPStatusCode200() добавьте XCTSkipUnless в начале теста:

try XCTSkipUnless(
  networkMonitor.isReachable, 
  "Network connectivity needed for this test.")

XCTSkipUnless(_: _ :) пропускает тест, если сеть недоступна. Проверьте это, отключив сетевое соединение и запустив тест. В поле рядом с тестом вы увидите новый значок, указывающий на то, что тест не прошел и не провалился.

Снова включите сетевое соединение и повторно запустите тест, чтобы убедиться, что он по-прежнему работает успешно в нормальных условиях. Добавьте тот же код в начало testApiCallCompletes().

Имитация объектов и взаимодействий

Асинхронные тесты дают вам уверенность в том, что ваш код генерирует правильный ввод для асинхронного API. Вы также можете проверить, правильно ли работает ваш код, когда он получает ввод от URLSession, или что он правильно обновляет базу данных UserDefaults или контейнер iCloud.
Большинство приложений взаимодействуют с объектами системы или библиотеки - объектами, которые вы не контролируете. Тесты, которые взаимодействуют с этими объектами, могут быть медленными и не повторяться, нарушая два принципа FIRST. Вместо этого вы можете имитировать взаимодействия, получая данные из stubs или обновляя mock-объекты.
Используйте имитацию, когда ваш код зависит от системного или библиотечного объекта. Сделайте это, создав фейковый объект, который играет эту роль, и вставьте этот объект в свой код. В Dependency Injection Джона Рида описывается несколько способов сделать это.

Имитация ввода из Stub

Теперь убедитесь, что getRandomNumber(completion:) правильно анализирует загруженные данные. Вы имитируете сеанс BullsEyeGame с помощью стаббов.

Перейдите в Test navigator, щелкните + и выберите New Unit Test Class…. Дайте ему имя BullsEyeFakeTests, сохраните его в каталоге BullsEyeTests и установите таргет на BullsEyeTests.

Импортируйте BullsEye модуль перед import:

@testable import BullsEye

Замените содержимое BullsEyeFakeTests этим:

var sut: BullsEyeGame!

override func setUpWithError() throws {
  try super.setUpWithError()
  sut = BullsEyeGame()
}

override func tearDownWithError() throws {
  sut = nil
  try super.tearDownWithError()
}

Это объявляет SUT, которым является BullsEyeGame, создает его в setUpWithError() и освобождает в tearDownWithError().
Проект BullsEye содержит вспомогательный файл URLSessionStub.swift. Он определяет простой протокол с именем URLSessionProtocol с методом создания data task с URL. Он также определяет URLSessionStub, который соответствует этому протоколу. Его инициализатор позволяет вам определять данные, ответ и ошибку, которые должна возвращать data task.
Для настройки этой имитации зайдите в BullsEyeFakeTests.swift и добавьте новый тест:

func testStartNewRoundUsesRandomValueFromApiRequest() {
  // given
  // 1
  let stubbedData = "[1]".data(using: .utf8)
  let urlString = 
    "http://www.randomnumberapi.com/api/v1.0/random?min=0&max=100&count=1"
  let url = URL(string: urlString)!
  let stubbedResponse = HTTPURLResponse(
    url: url, 
    statusCode: 200, 
    httpVersion: nil, 
    headerFields: nil)
  let urlSessionStub = URLSessionStub(
    data: stubbedData,
    response: stubbedResponse, 
    error: nil)
  sut.urlSession = urlSessionStub
  let promise = expectation(description: "Value Received")

  // when
  sut.startNewRound {
    // then
    // 2
    XCTAssertEqual(self.sut.targetValue, 1)
    promise.fulfill()
  }
  wait(for: [promise], timeout: 5)
}

В этом тесте:

1. Вы настраиваете фейковые данные и ответ, а также создаете фейковый объект сеанса. Наконец, добавляете фейковую сессию в приложение как свойство sut.
2. Вам все равно придется писать все это как асинхронный тест, потому что стаб претендует на роль асинхронного метода. Проверьте, парсит ли вызов startNewRound(completion:) фейковые данные, сравнивая targetValue с стаббированным фейковый номером. Запустите тест. Это должно произойти довольно быстро, потому что нет никакого реального сетевого подключения!

Имитация обновления для Мокированного объекта

В предыдущем тесте мы использовали стаб . Теперь вы воспользуетесь мокированным обьектом, чтобы проверить, правильно ли ваш код обновляет значения UserDefaults.
В этом приложении есть два игровых стиля. Пользователь может:

1. Переместить ползунок, чтобы угадать значение таргета.
2. Угадать значение по положению ползунка.

Сегментед контрол правом нижнем углу переключает стиль игры и сохраняет его в UserDefaults.
Следующий тест проверяет, правильно ли приложение сохраняет свойство gameStyle.
Добавьте новый тестовый класс в таргет BullsEyeTests и назовите его BullsEyeMockTests. Добавьте следующее под оператором import:

@testable import BullsEye

class MockUserDefaults: UserDefaults {
  var gameStyleChanged = 0
  override func set(_ value: Int, forKey defaultName: String) {
    if defaultName == "gameStyle" {
      gameStyleChanged += 1
    }
  }
}

MockUserDefaults переопределяет set(_:forKey:) для инкрементации gameStyleChanged. Подобные тесты часто устанавливают переменную Bool, но инкрементация Int дает вам большую гибкость. Например, ваш тест может проверить, что приложение вызывает метод только один раз.

Затем в BullsEyeMockTests объявите SUT и мокированный объект:

var sut: ViewController!
var mockUserDefaults: MockUserDefaults!

Замените setUpWithError() и tearDownWithError() на:

override func setUpWithError() throws {
  try super.setUpWithError()
  sut = UIStoryboard(name: "Main", bundle: nil)
    .instantiateInitialViewController() as? ViewController
  mockUserDefaults = MockUserDefaults(suiteName: "testing")
  sut.defaults = mockUserDefaults
}

override func tearDownWithError() throws {
  sut = nil
  mockUserDefaults = nil
  try super.tearDownWithError()
}

Это создает SUT и фейковый объект и внедряет мокированный объект как свойство SUT.
Теперь замените два метода тестирования по умолчанию в шаблоне следующим образом:

func testGameStyleCanBeChanged() {
  // given
  let segmentedControl = UISegmentedControl()

  // when
  XCTAssertEqual(
    mockUserDefaults.gameStyleChanged, 
    0, 
    "gameStyleChanged should be 0 before sendActions")
  segmentedControl.addTarget(
    sut,
    action: #selector(ViewController.chooseGameStyle(_:)),
    for: .valueChanged)
  segmentedControl.sendActions(for: .valueChanged)

  // then
  XCTAssertEqual(
    mockUserDefaults.gameStyleChanged, 
    1, 
    "gameStyle user default wasn't changed")
}

Утверждение when состоит в том, что флаг gameStyleChanged равен 0 до того, как метод тестирования изменит сегментед контрол. Итак, если утверждение then также верно, это означает, что set (_: forKey :) был вызван ровно один раз.
Запустите тест. Должно сработать.

UI тестирование в Xcode

UI тестирование позволяет тестировать взаимодействие с пользовательским интерфейсом. UI тестирование работает путем поиска объектов пользовательского интерфейса приложения с помощью запросов, синтеза событий и последующей отправки событий этим объектам. API позволяет вам изучить свойства и состояние объекта пользовательского интерфейса, чтобы сравнить их с ожидаемым состоянием.

В Test navigator добавьте UI Test Target. Убедитесь, что Target to be Tested это BullsEye, а затем примите имя по умолчанию BullsEyeUITests.

Откройте BullsEyeUITests.swift и добавьте свойство сверху класса BullsEyeUITests:

var app: XCUIApplication!

Удалите tearDownWithError() и замените содержимое setUpWithError() следующим:

try super.setUpWithError()
continueAfterFailure = false
app = XCUIApplication()
app.launch()

Удалите два существующих теста и добавьте новый под названием testGameStyleSwitch().

func testGameStyleSwitch() {    
}

Откройте новую строку в testGameStyleSwitch()и нажмите красную кнопку Record в нижней части окна редактора:

Это откроет приложение в симуляторе в режиме, который записывает ваши взаимодействия как тестовые команды. После загрузки приложения коснитесь в виде слайдера переключателя стиля игры и top label. Нажмите кнопку Xcode Record еще раз, чтобы остановить запись.

Теперь у вас три строчки в testGameStyleSwitch():

let app = XCUIApplication()
app.buttons["Slide"].tap()
app.staticTexts["Get as close as you can to: "].tap()

Рекордер создал код для тестирования тех же действий, которые вы тестировали в приложении. Тапните на стиль игры в сегментед контроле в top label. Вы будете использовать их как основу для создания собственного UI теста. Если вы видите какие-либо другие выражения, просто удалите их.

Первая строка дублирует свойство, которое вы создали в setUpWithError(), поэтому удалите эту строку. Пока вам не нужно ничего тапать, поэтому также удалите .tap() в конце строк 2 и 3. Теперь откройте небольшое меню рядом с ["Slide"] и выберите segmentedControls.buttons ["Slide"].

У вас должно остаться:

app.segmentedControls.buttons["Slide"]
app.staticTexts["Get as close as you can to: "]

Коснитесь любых других объектов, чтобы рекодер помог вам найти код, к которому вы можете получить доступ в своих тестах. Теперь замените эти строки этим кодом, чтобы создать раздел given:

// given
let slideButton = app.segmentedControls.buttons["Slide"]
let typeButton = app.segmentedControls.buttons["Type"]
let slideLabel = app.staticTexts["Get as close as you can to: "]
let typeLabel = app.staticTexts["Guess where the slider is: "]

Теперь, когда у вас есть имена двух кнопок в сегментед контроле и двух возможных верхних ярлыков, добавьте следующий код ниже:

// then
if slideButton.isSelected {
  XCTAssertTrue(slideLabel.exists)
  XCTAssertFalse(typeLabel.exists)

  typeButton.tap()
  XCTAssertTrue(typeLabel.exists)
  XCTAssertFalse(slideLabel.exists)
} else if typeButton.isSelected {
  XCTAssertTrue(typeLabel.exists)
  XCTAssertFalse(slideLabel.exists)

  slideButton.tap()
  XCTAssertTrue(slideLabel.exists)
  XCTAssertFalse(typeLabel.exists)
}

Этот код проверяет, существует ли правильный ярлык, когда вы tap() на каждой кнопке в сегментед контроле. Запустите тест - все выражения должны быть успешными.

Тестирование производительности

Из документации Apple:
Тест производительности берет блок кода, который вы хотите оценить, и запускает его десять раз, собирая среднее время выполнения и стандартное отклонение для запусков. Усреднение этих отдельных измерений формирует значение для тестового прогона, которое затем можно сравнить с базовым уровнем для оценки успеха или неудачи.

Написать тест производительности просто: просто поместите код, который вы хотите измерить, в клоужер measure(). Кроме того, вы можете указать несколько показателей для измерения.

Добавьте в BullsEyeTests следующий тест:

func testScoreIsComputedPerformance() {
  measure(
    metrics: [
      XCTClockMetric(), 
      XCTCPUMetric(),
      XCTStorageMetric(), 
      XCTMemoryMetric()
    ]
  ) {
    sut.check(guess: 100)
  }
}

Этот тест измеряет несколько показателей:

• XCTClockMetric измеряет сколько времени прошло.
• XCTCPUMetric отслеживает активность CPU, включая время CPU, циклы и количество инструкций.
• XCTStorageMetric сообщает вам, сколько данных тестируемый код записывает в хранилище.
• XCTMemoryMetric отслеживает объем используемой физической памяти.

Запустите тест, затем щелкните на значок, который появляется рядом с началом завершающего замыкания measure(), чтобы просмотреть статистику. Вы можете изменить выбранную метрику рядом с Metric.

Щелкните Set Baseline, чтобы установить контрольное время. Снова запустите тест производительности и просмотрите результат - он может быть лучше или хуже базового. Кнопка «Edit» позволяет сбросить Baseline (точку отсчета) до этого нового результата.
Baseline сохраняются для каждой конфигурации устройства, поэтому вы можете выполнять один и тот же тест на нескольких разных устройствах. Каждый может поддерживать разные базовые показатели в зависимости от скорости процессора, памяти и т. д.

Каждый раз, когда вы вносите изменения в приложение, которые могут повлиять на производительность тестируемого метода, снова запустите тест производительности, чтобы увидеть его сравнение с базовым уровнем.

Включение покрытия кода

Инструмент покрытия кода сообщает вам, какой код приложения на самом деле выполняется в ваших тестах, поэтому вы знаете, какие части приложения не протестированы - по крайней мере, пока.

Чтобы включить покрытие кода, отредактируйте действие Test и установите флажок Gather coverage for для во вкладке Options: