Как тестировать верстку (Layout) в iOS?

Да ты посмотри, какая хуйня, блядь! Тестирование верстки на iOS — это ж целый ёперный театр, один пиздец! Тут не просто ткнуть пальцем в небо, тут, сука, системный подход нужен, а то так и останешься с кривым интерфейсом, как мартышлюшка с гранатой.

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

Первый способ — снапшот-тесты, или «запомни, как должно выглядеть, и сравни, блядь».

• Суть: Ты делаешь скриншот эталонной верстки, сохраняешь его, как икону. А потом каждый раз, когда запускаешь тесты, программа делает новый скриншот и сравнивает пиксель в пиксель с эталоном. Малейшая разница — тест падает, и ты такой: «О, сука, что-то пошло не так».
• Чем тыкать: Берут обычно iOSSnapshotTestCase (старый добрый FBSnapshotTestCase) или Point-Free SnapshotTesting — это уже более модная штука.
• Вот, смотри, как это выглядит в коде, тут всё просто:

import iOSSnapshotTestCase

class MyViewSnapshotTests: FBSnapshotTestCase {
    func test_buttonLayout() {
        let button = UIButton()
        button.setTitle("Submit", for: .normal)
        button.sizeToFit()
        // А вот эта строка — магия, блядь. Она сравнивает вид кнопки с сохранённой картинкой.
        FBSnapshotVerifyView(button)
    }
}

• Важный нюанс, на котором все обжигаются: Запускать эту хуйню нужно на ОДНОМ И ТОМ ЖЕ симуляторе, с одинаковой версией iOS, а то получишь овердохуища ложных срабатываний. И не забудь про разные размеры экранов, про разный контент и про то, что в немецком языке слова длиннее, чем в русском, и всё съедет, пиздец.

Второй способ — юнит-тесты на логику. Тут уже не картинки, а математика, блядь.

• Суть: Ты проверяешь не красоту, а цифры. Правильно ли вычислилась высота? Тот ли отступ у констрейнта? Не съехал ли центр нахуй?
• Пример из жизни, чтоб понятнее было:

func test_viewHasCorrectConstraints() {
    let view = MyCustomView()
    view.layoutIfNeeded() // Обязательно говорим виду: «Давай, сука, расставь всё по местам, а потом уже будем проверять».

    XCTAssertEqual(view.frame.height, 44) // Проверяем, что высота ровно 44 пункта, а не 43,5, как у какой-то хитрой жопы.
    // А тут ищем конкретный констрейнт, который от левого края на 16 пунктов.
    let leadingConstraint = view.constraints.first {
        $0.firstAttribute == .leading && $0.constant == 16
    }
    XCTAssertNotNil(leadingConstraint) // Если не нашёлся — всё, пиши пропало, верстка поехала.
}

Ну и третий, самый тяжёлый артиллерийский снаряд — UI-тесты (XCUITest).

• Цель: Это уже не просто картинку сравнить или цифры проверить. Это запустить целое приложение на симуляторе или, охуенно, на реальном устройстве и проверить, как всё выглядит и работает в живую, когда пользователь тыкает во все дыры.
• Почему им реже тычут для чистой верстки? Да потому что они, блядь, МЕДЛЕННЫЕ, как черепаха в сиропе! Запуск, прогон — терпения ебать ноль. Но! Если у тебя сложный экран с анимациями, скроллами и прочей пиздопроебибной, то без них иногда никуда. Они как последняя инстанция, которая скажет: «Да, чувак, на реальном айпаде твоя сетка не разъезжается, как у полупидора на скользком полу».

Вот так вот, коротко и без воды. Главное — не зацикливайся на чём-то одном. Часто эти методы комбинируют: сначала быстрыми юнит-тестами проверили логику, потом снапшотами зафиксировали вид, а для ключевых сценариев написали тяжёлые UI-тесты. И тогда у тебя будет если не идеально, то хотя бы предсказуемо, а не как всегда — «ой, а у меня на дисплее 6.7 дюймов всё съехало, ядрёна вошь!».