Привет, Хабр! Меня зовут Дима, я iOS-разработчик в компании Doubletapp, и в прошлом году я вместе со своими коллегами и командой Яндекса участвовал в разработке приложения Яндекс Путешествия. В этом проекте мы выбрали фреймворком пользовательского интерфейса SwiftUI (подробнее о том, как мы его выбрали и что из этого получилось, рассказала наша iOS-Head Полина Скалкина здесь).

На начальном этапе реализации приложения мы постоянно вносили изменения во множество вью. Это были и обновления, вызванные переработкой дизайна, и исправление багов, и оптимизации, которые мы делали по мере роста наших знаний о SwiftUI. Нам хотелось контролировать все эти изменения, чтобы еще на этапе разработки отлавливать вызванные ими ошибки верстки. Поэтому наша команда приняла решение использовать snapshot-тесты.

Что такое snapshot-тесты?

Это вид тестов, сравнивающий некоторое представление объекта с эталонным представлением. В нашем случае объект тестирования — это вью, а представление — скриншот вью. Алгоритм простой: сначала создаётся скриншот-эталон и записывается на диск, после чего при очередном запуске тестов генерируется новый скриншот и сравнивается с сохранённым. Если скриншоты отличаются или эталон не найден, то тест не пройдёт.

Тесты такого типа дают нам возможность зафиксировать, как выглядит вью при разных состояниях модели (загрузка, данные, ошибка, авторизован/не авторизован и т.д.), цветовых схемах, размерах экрана. Множество вариаций snapshot’ов позволяет достичь необходимого нам контроля над изменениями вью.

Скриншоты можно хранить в репозитории вместе с кодом приложения. Тогда в pull request будет попадать не только код вью, но и её snapshot’ы. Благодаря этому ревьюер может посмотреть, как выглядит вью в разных конфигурациях. Кроме этого, в GitHub, GitLab и других сервисах есть встроенные инструменты сравнения картинок, которые помогут проверить изменения в скриншотах.

Для snapshot-тестирования мы выбрали библиотеку SnapshotTesting. Тесты в ней аналогичны привычным unit-тестам:

import SnapshotTesting
import XCTest

final class ExampleViewTests: XCTestCase {

   func testExampleView() {
       assertSnapshot(matching: ExampleView(), as: .image)
   }
}

Функция assertSnapshot работает по алгоритму, описанному выше: делает скриншот переданной вью и сравнивает его со скриншотом на диске. Если эталон на диске не найден, сохраняет только что созданный скриншот, и тест падает.

Нужно иметь в виду, что библиотека использует симулятор для создания скриншотов. На разных симуляторах и при разных настройках локали симулятора SnapshotTesting будет генерировать разные скриншоты. Поэтому команде нужно будет договориться, какой симулятор использовать.

Также может быть разница в скриншотах, генерируемых компьютерами на процессорах Intel и Apple Silicon. Это известная проблема, и пока что полностью её исправить не удаётся. Мы обходили это уменьшением параметров precision и perceptualPrecision, отвечающих за проверяемую степень сходства изображений. Если вам известны другие способы, буду рад узнать о них из комментариев.

Объединение snapshot-тестов и превью

После начала внедрения snapshot-тестов мы заметили, что они очень похожи на SwiftUI Previews. То есть достаточно написать необходимый инфраструктурный код, и при добавлении новых превью можно практически бесплатно получить snapshot-тесты для вью.

Нашу реализацию этой инфраструктуры можно разделить на две части: превью и snapshot-тесты. Соединяет эти части протокол Testable. Его роль — предоставить набор вариаций вью при разных состояниях модели (массив samples). Для этого определён associatedtype Sample, позволяющий минимизировать использование AnyView. Кроме того, в определении протокола можно заметить associatedtype Modifier, но о нём расскажу чуть позже.

import SwiftUI

public protocol Testable {
   associatedtype Sample: View
   associatedtype Modifier: PreviewModifier = IdentityPreviewModifier
  
   static var samples: [Sample] { get }
}

Если говорить про часть превью, то протокол Testable реализуется вместе с PreviewProvider и в некоторой степени заменяет его, поэтому для их связки задано следующее расширение:

extension PreviewProvider where Self: Testable {
   static var previews: some View {
       ForEach(samples, id: \.uuid) { $0 }
           .modifier(Modifier())
   }
}

private extension View {
   var uuid: UUID { UUID() }
}

Вот как выглядит определение превью в самом простом случае на примере экрана списка отелей:

struct HotelListView_Previews: PreviewProvider, Testable {
   static let samples = [
       HotelListView()
   ]
}

Вернёмся к associatedtype Modifier в протоколе Testable. Это модификатор, который применяется ко всем вью из массива samples. PreviewModifier, является расширением SwiftUI-протокола ViewModifier и определяет возможность инстанциировать его реализацию без знания её типа.

import SwiftUI

public protocol PreviewModifier: ViewModifier {
   init()
}

Modifier используются в случаях, когда нужно дополнительно настроить вью перед ее показом в превью и snapshot-тестах. Например, цвет фона экрана по умолчанию совпадает с фоном клетки отеля, и нам нужно его поменять, чтобы видеть границы вью. С помощью Modifier изменим цвет фона экрана:

struct HotelView_Previews: PreviewProvider, Testable {
   static let samples = [
       HotelView(state: .moscowHotel)
   ]
  
   struct Modifier: PreviewModifier {
       func body(content: Content) -> some View {
           content
               .frame(maxHeight: .infinity)
               .background(Color.major)
       }
   }
}

Если же ничего модифицировать не нужно, то используется IdentityPreviewModifier, который оставляет вью без изменений (используется по умолчанию):

public struct IdentityPreviewModifier: PreviewModifier {
   public init() {}
  
   public func body(content: Content) -> some View { content }
}

На этом с частью превью всё, перейдем к части snapshot-тестов. Её две главные задачи — это интеграция с библиотекой SnapshotTesting и уменьшение дублирования кода при написании тестов. 

Как было сказано ранее, каждый скриншот — это вью при заданном состоянии модели, размере и цветовой схеме. Различные состояния модели уже хранятся в массиве samples (протокол Testable), поэтому мы определили отдельную структуру SnapshotEnvironment для хранения размера (layout) и цветовой схемы (traits):

import SnapshotTesting
import UIKit

struct SnapshotEnvironment {
   let layout: SwiftUISnapshotLayout
   let traits: UITraitCollection
   let descriptionComponents: [String]
}

Поле descriptionComponents нужно при формировании имени скриншота. Далее будет показано, как оно создается и используется.

Чтобы зафиксировать размеры экранов устройств, которые интересны нам для тестирования, и поддерживаемые цветовые схемы, определены перечисления Device и Theme:

extension SnapshotEnvironment {
   enum Device: String {
       case iPhone13, iPhone8, iPhoneSe
      
       fileprivate var viewImageConfig: ViewImageConfig {
           switch self {
           case .iPhone13: return .iPhone13
           case .iPhone8: return .iPhone8
           case .iPhoneSe: return .iPhoneSe
           }
       }
   }
  
   enum Theme: String, CaseIterable {
       case light, dark
      
       fileprivate var traitCollection: UITraitCollection {
           UITraitCollection(userInterfaceStyle: interfaceStyle)
       }
      
       private var interfaceStyle: UIUserInterfaceStyle {
           switch self {
           case .light: return .light
           case .dark: return .dark
           }
       }
   }
}

Эти перечисления, в свою очередь, используются в фабричных методах тестовых конфигураций:

extension SnapshotEnvironment {
   static func device(_ device: Device, theme: Theme) -> SnapshotEnvironment {
       SnapshotEnvironment(
           layout: .device(config: device.viewImageConfig),
           traits: theme.traitCollection,
           descriptionComponents: [device.rawValue, theme.rawValue]
       )
   }
  
   static func sizeThatFits(theme: Theme) -> SnapshotEnvironment {
       SnapshotEnvironment(
           layout: .sizeThatFits,
           traits: theme.traitCollection,
           descriptionComponents: ["sizeThatFits", theme.rawValue]
       )
   }
}

В зависимости от вью, может потребоваться определённый набор тестовых конфигураций (размер + цветовая схема). Используемые у нас наборы заданы кейсами перечисления SnapshotBatch:

enum SnapshotBatch {
   case regular, extended, component
  
   var snapshotEnvironments: [SnapshotEnvironment] {
       switch self {
       case .regular:
           return SnapshotEnvironment.Theme.allCases.map { .device(.iPhone13, theme: $0) }
       case .extended:
           return SnapshotEnvironment.Theme.allCases.map { .device(.iPhone13, theme: $0) } + [
               .device(.iPhone8, theme: .light),
               .device(.iPhoneSe, theme: .light)
           ]
       case .component:
           return SnapshotEnvironment.Theme.allCases.map(SnapshotEnvironment.sizeThatFits)
       }
   }
}

И, наконец, весь ранее описанный код используется в методе test, выполняющем snapshot-тестирование элементов массива samples протокола Testable. Имя файла скриншота автоматически формируется из названия тестовой функции, которое подставляется в параметр testName, и поля descriptionComponents структуры SnapshotEnvironment, которое я показывал ранее.

import SnapshotTesting

extension Testable {
   static func test(
       batch: SnapshotBatch,
       file: StaticString = #file,
       testName: StaticString = #function,
       line: UInt = #line
   ) {
       let name = testName.description.removingPrefix("test").removingSuffix("()")
       for sample in samples.map({ $0.modifier(Modifier()) }) {
           for environment in batch.snapshotEnvironments {
               assertSnapshot(
                   matching: sample,
                   as: .image(layout: environment.layout, traits: environment.traits),
                   file: file,
                   testName: assembleTestName(name, for: environment),
                   line: line
               )
           }
       }
   }
  
   private static func assembleTestName(_ testName: String, for environment: SnapshotEnvironment) -> String {
       ([testName] + environment.descriptionComponents).joined(separator: "-")
   }
}

Инфраструктура готова! Теперь для полного тестирования вью достаточно вызвать метод test и передать в него нужный SnapshotBatch. Например, в случае HotelListView snapshot-тестирование будет выглядеть так:

func testHotelListView() {
   HotelListView_Previews.test(batch: .extended)
}

В результате выполнения теста будут сгенерированы скриншоты

• HotelListView-iPhone13-light.1.png

• HotelListView-iPhone13-dark.1.png

• HotelListView-iPhone8-light.1.png

• HotelListView-iPhoneSe-light.1.png

Цифра после точки в имени файла добавляется библиотекой автоматически и в нашем случае указывает на номер элемента в массиве samples.

Итог

Применение snapshot-тестов удовлетворило нашу потребность в контроле над изменениями, которые постоянно вносились во вью. Кроме того, хранящиеся в репозитории с кодом скриншоты экранов сделали процесс ревью UI-компонентов гораздо более удобным. Благодаря этому мы своевременно отлавливали ошибки верстки еще до вливания изменений в основную ветку проекта.

Созданная вокруг библиотеки SnapshotTesting инфраструктура сделала написание snapshot-тестов легким и быстрым. Решение получилось достаточно гибким, так что с небольшими доработками его можно использовать и на других проектах.

Узнать подробнее о долгосрочном опыте применения snapshot-тестов и результатах использования описанного инструмента в Яндекс Путешествиях можно на докладе от автора идеи, Николая Пучко, на Vertis Mobile Meetup 13 октября.