Нативная разработка мобильных приложений

Product 
⇒
 Test
(Продукт 
⇒
Тест). В результате рядом с тестом 
в XCode появится зеленая галочка, подсказывающая, что тест выполнился 
успешно.
Теперь рассмотрим весь класс с тестами. Прямо сейчас 
CalculatorTests
вы
-
глядит так:
class CalculatorTests: XCTestCase {
override func setUp() {
}
override func tearDown() {
}
func testExample() {
}
}
Обратите внимание на несколько важных аспектов. Прежде всего класс 
Cal­
culatorTests
, вмещающий все тесты для класса 
Calculator
, наследует 
XCTestCase
. 
В нем определен тест 
testExample
, который будет запущен и должен выполнить 
некоторые проверки, каждая из которых может завершиться успехом или не
-
удачей.
Есть несколько стандартных проверок, таких как:
 

XCTAssert()
– принимает выражение и возвращает логическое значение;
 

XCTAssertFalse()
и 
XCTAssertTrue()
– проверяют конкретное логическое 
значение;
 

XCTAssertEquals()
и 
XCTAssertNotEqual()
– проверяют равенство объектов;
 

XCTAssertNil()
и 
XCTAssertNotNil()
– проверяют, является ли ссылка пустой 
(
nil
). 
Чтобы выполнить эти проверки, достаточно просто добавить их в тело ме
-
тода:
func testExample() {
let success = false
XCTAssertTrue(success)
}
Эта проверка приведет к неудачному завершению теста, потому что в пре
-
дыдущей строке параметру 
success
присваивается значение 
false
. Когда про
-
верка терпит неудачу, тест считается непройденным. Проверки довольно 
просты в использовании, и в одном тесте можно использовать несколько 
проверок.
В тестовом классе также есть методы 
setUp()
и 
tearDown()
. Это стандартные 
методы, которые вызываются до и после запуска каждого теста в этом классе 
соответственно. Как вы уже наверняка догадались, 
setUp()
реализует настрой
-
ку теста и испытуемого объекта, а 
tearDown()
освобождает использовавшиеся 
ресурсы. Например, в 
setUp()
мы могли бы создать экземпляр 
Calculator
для 
тестирования и сохранить его в переменной 
sut
, а в 
tearDown()
уничтожить его 
после тестирования. Например:

---

224

Тестирование
class CalculatorTests: XCTestCase {
var sut: Calculator!
override func setUp() {
self.setUp()
sut = Calculator()
}
override func tearDown() {
sut = nil
self.tearDown()
}
func testTwoPlusTwoEqualsFour() {
let result = sut.enter(2).add(2)
XCTAssertEqual(result, 4)
}
}
Иногда требуется протестировать асинхронные функции. Это сложно, пото
-
му что тестовый метод будет завершаться до того, как выполнится асинхрон
-
ный код. Асинхронный код вообще очень сложно отлаживать. Однако меха
-
низм ожиданий в фреймворке тестирования избавляет нас от этой проблемы. 
Например:
func testAsynchronousCode() {
let expectation = XCTestExpectation(description:
"Asynchronous code will return true.")
sut.enter(2).add(2).shareToTwitter { (success) in
if success {
expectation.fulfill()
} else {
XCTFail("Sharing to Twitter did not work.")
}
}
waitForExpectations(timeout: 2.0) { (error) in
XCTFail("Test failed.")
}
}
В этом примере сначала создается экземпляр ожидания 
XCTestExpectation
для 
выполнения в асинхронном коде. Затем фиктивному методу 
shareToTwitter(:)
передается замыкание, которое выполнится после публикации результатов вы
-
числений калькулятора в Twitter. Потом проверяется значение 
success
и, если 
оно равно 
true
, вызывается метод 
fulfill()
экземпляра ожидания, чтобы сооб
-
щить Xcode, что тест пройден, иначе вызывается 
XCTFail()
, чтобы сообщить, что 
произошла ошибка. В заключение вызывается 
waitForExpectations(timeout::)
, 
чтобы дождаться завершения ожидания, установив тайм-аут равным двум се
-
кундам. Если к тому времени ожидание не выполнится, будет вызван 
XCTFail()
, 
который сообщит, что тест не пройден.
Мы надеемся, что модульное тестирование в Xcode и iOS не выглядит та
-
ким страшным, каким могло бы вам показаться. Теперь перейдем к интегра
-

---

Что мы узнали 
