Тестирование на Swift долгие годы держалось на трех китах: XCTest, сторонние библиотеки и собственная смекалка. Но на WWDC 24 Apple представила новый, современный фреймворк — Swift Testing, который предлагает концептуально новый подход к тестированию.
Меня зовут Кирилл Гусев. Я мобильный разработчик в ОК. В этой статье я расскажу о том, какие возможности предоставляет Swift Testing.
Начнем со знакомства: немного о Swift Testing
Swift Testing — новый фреймворк для юнит-тестирования от Apple, представленный на WWDC 24 и призванный заменить классический XCTest. Swift Testing имеет открытый исходный код и разработан с учетом современных возможностей Swift.
Фреймворк поддерживает макросы и Swift Concurrency, а также является кроссплатформенным решением — работает на всех платформах, где есть Swift (macOS, iOS, Linux, Windows), что критично для серверной разработки и создания универсальных инструментов.
Вместе с тем, у фреймворка пока остаются некоторые ограничения. Например, он не поддерживает UI-тесты, работу с Performance и Objective-C код. Но даже при этом Swift Testing стал достойной альтернативой XCTest — этому способствует набор новых фич и возможностей. Остановимся на них подробнее.
Новые фичи
Для начала познакомимся с новыми функциями, доступными во фреймворке.
@Test
В Swift Testing реализована поддержка аннотации @Test. Благодаря этому, для определения теста теперь не обязательно создавать класс, который будет наследоваться от XCTestCase — достаточно создать функцию с аннотацией @Test.
import Testing
@Test
func foodTruckExists() {
// Test logic goes here.
}
При этом в аннотации можно задать имя теста, чтобы легче было идентифицировать его назначение.
@Test("Food truck exists")
func foodTruckExists() {
// Test logic goes here.
}
Также можно добавлять атрибуты-модификаторы MainActor и async throws.
@Test
@MainActor
func foodTruckExists() async throws {
// Test logic goes here.
}
Изменения жизненного цикла теста
В XCTest тесты привязаны исключительно к классам. Но в Swift Testing есть возможность использовать как классы, так и структуры.
Так, если раньше для setUp и tearDown были отдельные функции, то сейчас достаточно определить init и deinit для тестов.
@Suite
Вместе с поддержкой @Test, в Swift Testing поддерживается аннотация @Suite, которая используется в тестировании для объединения нескольких тестовых классов или групп тестов в один набор (suite).
@Suite("Arithmetic")
struct ArithmeticTests {
let calc = Calculator()
@Test
func addition() {
let result = calc.addition(num1: 2, num2: 3)
#expect(result == 5)
}
@Test
func subtraction() {
let result = calc.subtraction(num1: 5, num2: 3)
#expect(result == 2)
}С ее помощью можно:
группировать тесты в один набор;
вкладывать Suite внутри друг друга для создания иерархии тестов;
применять дополнительные настройки и модификаторы (Traits или трейты) ко всем тестам в Suite одновременно;
настраивать отображение набора в Xcode и в результатах тестов.
При этом @Suite необязателен для работы, поскольку Swift Testing распознаёт тесты, находящиеся в любом типе (структуре, классе, акторе). Вместе с тем, @Suite позволяет явно задать имя и дополнительные параметры.
Expectation
В Swift Testing можно использовать expectation — механизм для проверки условий (утверждений) в тестах, который, в отличие от традиционных XCTAssert-функций из XCTest, использует более современный и гибкий подход через макрос #expect().
Примечательно, что функция expect сообщает о неудаче, но позволяет тесту продолжать выполнение. Это удобно, поскольку дает возможность посмотреть все ожидания, которые падают во время теста.
Например, у нас есть структура calculator и функция sum. Мы хотим проверить, что сумма будет равна разным значениям.
В примере видим, что первые два ожидания не оправдались, но тест завершился и проверил все ожидания.
#require
Функция require — аналог #expect, но с немедленным прекращением выполнения теста (с ошибкой ExpectationFailedError) при неудачной проверке.
Также она может использоваться для разворачивания опционалов. Это аналог XCTUnwrap, который был в XCTest.
@Test
func stringParsesToInt() throws {
let data = "2"
let parsed = try #require(Int(data))
#expect(parsed == 2)
}Запись ошибок
В Swift Testing появилась возможность логировать ошибки при помощи Issue.record(), в которой мы можем залогировать причины падения теста.
Например, у нас может быть функция, которая описывает, что двигатель условного фургончика с едой может быть электрическим или дизельным.
enum Engine {
case electric
case diesel
}
struct FoodTruck {
static let shared = FoodTruck()
var engine: Engine = .diesel
}И мы можем запустить тест, в условиях которого задаем, что тест может упасть, если двигатель не электрический.
struct FoodTruckTests {
@Test
func engineWorks() {
let engine = FoodTruck.shared.engine
guard case .electric = engine else {
Issue.record("Engine is not electric")
return
}
// ...
}
}Так как у нас двигатель не электрический, тест объективно упадет.
withKnownIssue
withKnownIssue — параметр аннотации @Test, который помечает тест как содержащий известную проблему (баг). Его использование дает возможность:
запускать тест, но не считать его провал как
failure;отслеживать известные проблемы;
получать предупреждения при неожиданном успехе.
Например, возьмем тест, в котором grillWorks помечен как имеющий известную проблему — "Grill is out of fuel". В этом случае, если при выполнении теста возникнет ошибка, связанная с тем, что гриль не может быть запущен из-за отсутствия топлива, тест не будет считаться проваленным.
struct FoodTruckTests {
@Test
func grillWorks() async {
withKnownIssue("Grill is out of fuel") {
try FoodTruck.shared.grill.start()
}
// ...
}
}withKnownIssue также позволяет указывать, если ошибка интермиттирующая, то есть проявляется не всегда, а только в определенных условиях. Это означает, что тесты должны быть готовы к тому, что ошибка может возникать не всегда, а только в определенных условиях.
struct FoodTruckTests {
@Test
func grillWorks() async {
withKnownIssue("Grill may need fuel", isIntermittent: true) {
try FoodTruck.shared.grill.start()
}
// ...
}
}Функция withKnownIssue также позволяет задавать условия, при которых известная проблема считается актуальной, и сопоставлять ошибки с определенными критериями.
Например, можно указать, что проблема с отсутствием топлива в гриле актуальна только при условии, что гриль установлен (FoodTruck.shared.hasGrill). Также проверять, что в объекте issue есть ошибка (issue.error != nil), чтобы считать проблему актуальной.
struct FoodTruckTests {
@Test
func grillWorks() async {
withKnownIssue("Grill is out of fuel") {
try FoodTruck.shared.grill.start()
} when: {
FoodTruck.shared.hasGrill
} matching: { issue in
issue.error != nil
}
// ...
}
}Кастомизация тестов
Swift Testing предлагает возможность использования различных трейтов, с помощью которых можно:
задать дополнительное поведение или метаданные к тестам и
test suite;настраивать выполнение тестов;
добавлять описания, теги, ограничения по времени и многое другое.
Разберем несколько наглядных примеров.
Выключение тестов
Например, можно выключить тест, который не нужен.
@Test("Food truck sells burritos", .disabled())
func sellsBurritos() async throws {
// ...
}Также можно указать причину, по которой выключается определенный тест:
@Test("Food truck sells burritos", .disabled("We only sell Thai cuisine"))
func sellsBurritos() async throws {
// ...
}Помимо этого, можно выключать Suite и все определенные в нем тесты.
@Suite("Arithmetic", .disabled())
struct ArithmeticTestsЗапуск теста при определенном условии
Также с помощью трейтов можно настраивать запуск теста при определенном условии. Например, чтобы тест запускался только летом.
enum Season {
case winter
case spring
case summer
case autumn
static var current: Season = .summer
}
@Test("Ice cream is cold", .enabled(if: Season.current == .summer))
func isCold() async throws {
// ...
}Примечательно, что два упомянутых условия для теста можно комбинировать — например, выключить тест на всё время, но включать только летом.
@Test(
"Ice cream is cold",
.enabled(if: Season.current == .summer),
.disabled("We ran out of sprinkles")
)
func isCold() async throws {
// ...
}Добавление тегов
Помимо этого, в Swift Testing появилась возможность использования тегов. То есть, теперь можно не только объединять в группы похожие тесты, но и присваивать им одинаковые теги для упрощения последующего использования — можно создать новый тег, расширив его и добавив статическую переменную.
extension Tag {
@Tag static var example: Tag
enum CustomTags {}
}
extension Tag.CustomTags {
@Tag static var jsonTests: Tag
}Достаточно просто добавить в аннотацию свойства tags, и в Xcode пометятся все тесты с определенным тегом.
Например, задаем некоторые функции:
@Test("Decode json", .tags(.CustomTags.jsonTests))
func decodeJson()
@Test(.tags(.example))
func decodeJSONTypeCastingFails()
@Suite(.tags(.CustomTags.jsonTests))
struct JSONDecoderTestsА на выходе получаем две группы тестов по тегам:
CustomTags.jsonTests;example.
В дальнейшем такая сортировка не только упрощает поиск похожих тестов, но и позволяет запускать все тесты с одним тегом одновременно.
Линковка багов
Помимо прочего, в Swift Testing доступен удобный механизм линковки багов. Так, упавший тест с неожиданным поведением можно выключить и слинковать с задачей, с которой он будет фикситься.
@Test(.disabled(), .bug(«https://jira.vk.team/browse/OKAT-6683", "Баг"))
func responseSerializerFailsDataIsNil() throwsПри этом, в интерфейсе предусмотрена отдельная кнопка, которая позволяет сразу перейти к нужной задаче.
Создание кастомного трейта
Также в Swift Testing можно создавать кастомные трейты. Это может пригодиться, например, чтобы инкапсулировать часто используемые конфигурации тестов (например, переопределённые зависимости, специальные настройки окружения, общие параметры). То есть, вместо повторения одной и той же логики в каждом тесте или Suite можно создать один кастомный трейт и применять его везде.
Для этого достаточно создать структуру или класс, который будет подписан на протокол TestTrait, и расширить трейт, подписав на нужный трейт с помощью статической переменной.
@Test(.mockJson)
func example() {
// ...
}
struct MockJsonTrait: TestTrait { }
extension Trait where Self == MockJsonTrait {
static var mockJson: Self { }
}Параметризованные тесты
Одной из важных фишек Swift Testing стала возможность создания параметризированных тестов, то есть тех, которые выполняются многократно с разными наборами входных данных. Это позволяет проверить одну и ту же функциональность с различными значениями, чтобы убедиться в ее правильности в разных случаях.
Параметризация теста
Рассмотрим ситуацию, где нам надо проверить тест, в котором есть определенное количество аргументов. Для этого создадим enum или массив, и пробежимся по нему.
enum Food {
case burger, iceCream, burrito, noodleBowl, kebab
}Теоретически можно создать тест, который через for loop проверяет каждый аргумент: в нашем случае — возможность приготовления каждого вида еды.
enum Food {
case burger, iceCream, burrito, noodleBowl, kebab
}
@Test("All foods available")
func foodsAvailable() async throws {
for food: Food in [.burger, .iceCream, .burrito, .noodleBowl, .kebab] {
let foodTruck = FoodTruck(selling: food)
#expect(await foodTruck.cook(food))
}
}Но со Swift Testing тест можно упростить, передав все аргументы в аннотацию, что облегчит его понимание.
enum Food {
case burger, iceCream, burrito, noodleBowl, kebab
}
@Test("All foods available", arguments: [Food.burger, .iceCream, .burrito, .noodleBowl, .kebab])
func foodAvailable(_ food: Food) async throws {
let foodTruck = FoodTruck(selling: food)
#expect(await foodTruck.cook(food))
}Помимо этого, для enum можно добавить CaseIterable. В таком случае в аргументы можно просто передать значение allCases, что будет подразумевать проверку всех аргументов.
enum Food: CaseIterable {
case burger, iceCream, burrito, noodleBowl, kebab
}
@Test("All foods available", arguments: Food.allCases)
func foodAvailable(_ food: Food) async throws {
let foodTruck = FoodTruck(selling: food)
#expect(await foodTruck.cook(food))
}Но применение параметризированных тестов возможно и в более сложных кейсах. Например, когда в тесте указывается два массива.
Рассмотрим на функции, которая проверяет нормальную частоту биения сердца в каждом из возрастов. В теории массивы значений можно проверить через for loop.
@Test
func verifyNormalHeartRate() {
let age = [18, 30, 50, 70]
let bpm = [77.0, 73, 65, 61]
for (age, bpm) in zip(age, bpm) {
let hr = HeartRate(bpm: bpm)
let context = HeartRateContext(age: age, activity: .regular, heartRate: hr)
#expect(context.zone == .normal)
}
}Но рациональнее передать два массива в аргументы.
@Test(arguments: [18, 30, 50, 70], [77.0, 73, 65, 61])
func verifyNormalHeartRate(age: Int, bpm: Double) {
let hr = HeartRate(bpm: bpm)
let context = HeartRateContext(age: age, activity: .regular, heartRate: hr)
#expect(context.zone == .normal)
}Но здесь возникает проблема. Так, в исходном варианте применяется zip, что позволяет проверять значения только парами. А при передаче массивов в аргументы можно получить 25 прогонов, поскольку Swift Testing будет пытаться проверить все возможные варианты. Соответственно, чтобы избежать подобных издержек, также нужно использовать zip для тестирования конкретных пар.
@Test(arguments: zip([18, 30, 50, 70], [77.0, 73, 65, 61]))
func verifyNormalHeartRate(age: Int, bpm: Double) {
let hr = HeartRate(bpm: bpm)
let context = HeartRateContext(age: age, activity: .regular, heartRate: hr)
#expect(context.zone == .normal)
}Это позволит сразу найти пару, которая будет падать, а не перебирать 25 раз.
Лимиты времени
В рамках параметризации тестов также можно применять некоторые Traits. Например, можно ограничивать время тестов в минутах.
@available(iOS 16.0, *)
@Test(.timeLimit(.minutes(1)))
func prepare(food: Food)Надо отметить, что функция пока доступна только с iOS 16.
Выключение параллельности
Также можно выключать параллельность запуска тестов. Например, если нужно последовательно проверить возможность приготовления каждого блюда. Для этого достаточно указать в функции условие serialized.
@Test(.serialized, arguments: Food.allCases)
func prepare(food: Food) {
// This function will be invoked serially, once per food, because it has the
// .serialized trait.
}Также serialized работает и для Suite. Например, пока последовательная проверка каждого аргумента не выполнится, второй тест не начнет свою работу.
@Suite(.serialized)
struct FoodTruckTests {
@Test(arguments: Condiment.allCases)
func refill(condiment: Condiment) {
// This function will be invoked serially, once per condiment, because the
// containing suite has the .serialized trait.
}
@Test
func startEngine() async throws {
// This function will not run while refill(condiment:) is running.
// One test must end before the other will start.
}
}Возможности миграции с XCTest к Swift Testing
Теперь остановимся на том, как потенциально можно применить все упомянутые возможности Swift Testing. Для наглядности рассмотрим несколько сценариев.
Декодинг JSON
Для декодинга JSON в XCTest классически применяется довольно типовая структура.
import XCTest
class JSONDecoderTests: OKTestCase {
func testJSONDecodingTypeCastingFails() {
let dataDecoder = JSONDecoder()
let data = Data("{\"uid\": 12, \"firstName\": \"firstName\", \"lastName\": \"lastName\"}".utf8)
let result = Result { try dataDecoder.decode(String.self, from: data) }
XCTAssertTrue(result.isFailure)
XCTAssertNil(result.success)
XCTAssertNotNil(result.failure)
}
}При работе со Swift Testing мы можем значительно упростить ее: сделать структуру (struct JSONDecoderTests), повесить аннотацию @Test и заменить XCTAssert на #expect.
import Testing
struct JSONDecoderTests {
@Test
func decodeJSONTypeCastingFails() {
let dataDecoder = JSONDecoder()
let data = Data("{\"uid\": 12, \"firstName\": \"firstName\", \"lastName\": \"lastName\"}".utf8)
let result = Result { try dataDecoder.decode(String.self, from: data) }
#expect(result.isFailure)
#expect(result.success == nil)
#expect(result.failure != nil)
}
}Замена setUp и tearDown
Помимо прочего, переход на Swift Testing позволит уйти от применения setUp и tearDown в тестах перформанса.
import XCTest
final class OKPerformanceModuleTests: XCTestCase {
private var collector: StorageCollector!
private var scenarioId: String?
override func setUpWithError() throws {
self.scenarioId = nil
self.collector = StorageCollector()
OKPerfomanceModule.attachCollector(self.collector)
}
override func tearDownWithError() throws {
if let scenarioId {
OKPerfomanceModule.end(scenarioId: scenarioId, message: nil)
}
}
}Так, setUp и tearDown можно заменить на init и deinit.
import Testing
final class OKPerformanceModuleTests {
private var collector: StorageCollector
private var scenarioId: String?
init() {
self.scenarioId = nil
self.collector = StorageCollector()
OKPerfomanceModule.attachCollector(self.collector)
}
deinit {
if let scenarioId {
OKPerfomanceModule.end(scenarioId: scenarioId, message: nil)
}
}
}Объединение логики повторяющихся тестов
Иногда тесты могут отличаться лишь некоторыми параметрами. Но в случае XCTest с этим часто приходится мириться. Например:
final class OKPerfomanceModuleTests: XCTestCase {
// ...
func testBeginChildCallNoMessage() throws {
let parentId = UUID().uuidString
let scenario = "testBeginChildCallNoMessage-scenario"
self.scenarioId = OKPerfomanceModule.begin(scenario: scenario,
parentId: parentId,
message: nil)
XCTAssertTrue(collector.scenario == scenario)
XCTAssertTrue(collector.parentId == parentId)
XCTAssertTrue(collector.message == nil)
}
func testBeginChildCallWithMessage() throws {
let parentId = UUID().uuidString
let scenario = "testBeginChildCallWithMessage-scenario"
let message = "testBeginChildCallWithMessage-message"
self.scenarioId = OKPerfomanceModule.begin(scenario: scenario,
parentId: parentId,
message: message)
XCTAssertTrue(collector.scenario == scenario)
XCTAssertTrue(collector.parentId == parentId)
XCTAssertTrue(collector.message == message)
}
}При работе со Swift Testing мы можем объединить два теста в один параметризованный. Например, можно создать аргумент и передать в него параметры, которые будут запускаться и проверяться в конкретном тесте.
final class OKPerfomanceModuleTests {
@Test(arguments: [
Argument(scenario: "testBeginRootCallNoMessage"),
Argument(scenario: "testBeginRootCallWithMessage-scenario", message: "testBeginRootCallWithMessage-message"),
])
func beginScenario(arg: Argument) {
self.scenarioId = OKPerfomanceModule.begin(scenario: arg.scenario, parentId: arg.parentId, message: arg.message)
#expect(collector.scenario == arg.scenario)
#expect(collector.parentId == arg.parentId)
#expect(collector.message == arg.message)
}
}
struct Argument {
let scenario: String
let parentId: String?
let message: String?
init(scenario: String, parentId: String? = UUID().uuidString, message: String? = nil) {
self.scenario = scenario
self.parentId = parentId
self.message = message
}
}
Переход от XCTUnwrap к require
Тесты в XCTest нередко используют XCTUnwrap.
class OKDecodableBatchResponseSerializerTests: OKTestCase {
func testResponseSerializerFailsDataIsNil() throws {
let serializer = DecodableTestBatchResponseSerializer()
serializer.registry(User.self, forKey: .user)
let result = Result { try serializer.serialize(response: nil, data: nil) }
let networkError = try XCTUnwrap(result.failure?.asNetworkingError)
XCTAssertEqual(networkError.isInputDataNilOrZeroLength, true)
}
}Со Swift Testing мы можем начать использовать require. Для этого достаточно заменить XCTUnwrap на require и Assert на expect.
struct OKDecodableBatchResponseSerializerTests {
@Test
func responseSerializerFailsDataIsNil() throws {
let serializer = DecodableTestBatchResponseSerializer()
serializer.registry(User.self, forKey: .user)
let result = Result { try serializer.serialize(response: nil, data: nil) }
let networkError = try #require(result.failure?.asNetworkingError)
#expect(networkError.isInputDataNilOrZeroLength)
}
}Логирование ошибок
Также можно залогировать ошибку, которая есть в тесте. Например, если результат успешный — выполняем определенную часть теста, если нет — выбрасывается ошибка.
class JSONDecoderTests: OKTestCase {
func testJSONDecoding() {
let dataDecoder = JSONDecoder()
let data = Data("{\"uid\": 12, \"firstName\": \"firstName\", \"lastName\": \"lastName\"}".utf8)
let result = Result { try dataDecoder.decode(OKAPIUser.self, from: data) }
XCTAssertTrue(result.isSuccess)
XCTAssertNotNil(result.success)
XCTAssertNil(result.failure)
if let user = result.success {
XCTAssertEqual(user.uid, 12)
XCTAssertEqual(user.firstName, "firstName")
XCTAssertEqual(user.lastName, "lastName")
} else {
XCTFail("Serialized result type is not dictionary: \(type(of: result.success))")
}
}
}Здесь можно несколько изменить конфигурацию через Guard, предусмотреть обработку ошибки через Issue.record и добавить expect.
struct JSONDecoderTests {
@Test
func decodeJson() {
let dataDecoder = JSONDecoder()
let data = Data("{\"uid\": 12, \"firstName\": \"firstName\", \"lastName\": \"lastName\"}".utf8)
let result = Result { try dataDecoder.decode(OKAPIUser.self, from: data) }
#expect(result.isSuccess)
#expect(result.success != nil)
#expect(result.failure == nil)
guard let user = result.success else {
Issue.record("Serialized result type is not dictionary: \(type(of: result.success))")
return
}
#expect(user.uid == 12)
#expect(user.firstName == "firstName")
#expect((user.lastName == "lastName"))
}
}
Вместо выводов
Swift Testing представляет собой современный фреймворк с интуитивным API, который предоставляет поддержку Swift Concurrency, параметризации и кастомизации тестов, модификации их поведения и множество других возможностей, с которыми работа разработчиков и тестировщиков становится проще. Именно поэтому мы в ОК уже начали переводить тесты на Swift Testing и получать результаты от внедрения нового фреймворка.
О том, как будет продвигаться наша работа с новым инструментом — обязательно расскажем в одной из следующих статей.