Что проверить на удалённом Mac до первого запуска fastlane scan?

Сначала убедитесь, что на узле доступен требуемый проекту Xcode, а выбранный проект или workspace действительно содержит нужную схему и тестовую цель. Затем зафиксируйте способ управления Ruby и зависимостями fastlane, проверьте доступный список устройств Simulator и повторите запуск из чистого рабочего каталога. Так ошибки окружения не смешаются с дефектами тестов.

С чего начать, если fastlane scan не находит Simulator?

Проверьте, какой Xcode выбран для текущего пользователя и процесса CI, затем запросите список доступных назначений у установленного Xcode и сопоставьте его с указанной в lane моделью и версией ОС. Если узел работает без графического входа, отдельно выясните, завершена ли первоначальная подготовка Simulator. Не подменяйте отсутствующее устройство похожим без фиксации этого изменения.

Как сохранить результаты, если удалённый тест завершился ошибкой?

Задайте отдельный путь для результатов и настройте в CI сбор файлов после завершения задачи независимо от её статуса. Сохраняйте журнал команды и пакет результатов Xcode, а затем проверяйте, что артефакты доступны после неуспешного задания и их можно скачать для разбора. Само наличие команды выгрузки в конфигурации не доказывает, что файлы переживут очистку рабочего каталога.

Успешный прогон fastlane scan заменяет проверку на настоящем iPhone или iPad?

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

CI/CD 18 октября 2026 г. ~10 мин fastlane удалённый Mac

Как запускать тесты fastlane scan на удалённом Mac? Руководство 2026

Руководство для iOS-разработчиков и инженеров, которым нужно перенести тесты fastlane scan на удалённый Mac и проверить, что результаты можно воспроизвести и сохранить. Последовательно рассмотрены подготовка окружения, настройка тестовой задачи, пробный запуск, файлы результатов и критерии допуска к CI; отдельно обозначена граница между тестированием в Simulator и проверкой на устройстве.

Симптом: fastlane scan запускается, но тесты на удалённом узле не подтверждены, а файлы результата могут потеряться.
Быстрое решение: сначала проверьте схему, выбранный Xcode и доступную цель Simulator, затем выполните небольшой тест и убедитесь, что пакет результатов сохраняется; только после этого подключайте задачу к CI.

Это руководство для iOS-разработчиков, которым нужно воспроизводимо запускать тесты проекта на удалённом Mac.
Оно также пригодится CI-инженерам, отвечающим за журналирование и сохранение результатов, и небольшим командам, оценивающим удалённую машину для тестовой работы.

Граница ответственности fastlane scan и удалённого Mac

fastlane scan — это удобный способ вызвать тестовый процесс проекта, а не самостоятельная среда выполнения и не доказательство того, что тесты действительно прошли. Для запуска необходим Mac с подходящими проекту инструментами Apple, а итог подтверждают статус тестирования и доступные результаты, а не только сообщение о старте команды. Назначение scan и run_tests описано в официальном руководстве fastlane по запуску iOS-тестов.

Для этой инструкции целевой сценарий — тесты iOS-приложения в Simulator на удалённом Mac. Мы не рассматриваем полное развёртывание CI, сравнение разных систем Runner или отдельный каталог способов исправить Simulator. Сначала устанавливается воспроизводимый для узла цикл: подготовить проект, указать тестовую схему, выполнить пробный запуск, сохранить результат и проверить восстановление.

Важно разделять три события:

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

Только последнее даёт основание оценивать готовность задачи к CI. Даже тогда успешный прогон в Simulator не заменяет проверку поведения приложения на физическом устройстве.

Первый этап: зафиксируйте базовую конфигурацию узла

До настройки lane запишите, что именно должно совпадать между рабочей машиной и удалённым узлом. Важны не абстрактные «последние версии», а версии и настройки, которые требует сам проект: выбранная схема, настройки проекта, способ установки Ruby и зависимости fastlane. Конкретную совместимость нельзя предполагать без проверки конфигурации проекта и используемого Xcode.

Начните с рабочего каталога, который содержит правильный проект или workspace. Проверьте, что в репозитории есть нужный тестовый target, а используемая схема доступна выбранному пользователю. Если проект хранит зависимости в lock-файле, сохраняйте его в процессе переноса и устанавливайте зависимости тем же проектным способом. Не заменяйте закреплённые версии обновлением «для проверки»: так будет сложнее определить, вызван ли сбой удалённой средой или изменением инструментов.

Затем подтвердите выбранную командную среду Xcode. Команда CI может запускаться не в той сессии пользователя, где ранее открывали Xcode, поэтому выбранный инструмент следует проверять именно из той оболочки, которая будет выполнять fastlane. Сопоставьте настройки с документацией Apple по инструментам командной строки Xcode. Там описаны средства командной строки; наличие установленного приложения само по себе ещё не подтверждает, что нужный инструмент выбран текущим процессом.

Перед первым прогоном соберите короткий базовый перечень:

путь к проекту или workspace и название схемы;
наличие тестовой цели и, если проект использует её, тестового плана;
выбранный Xcode, способ управления Ruby и порядок установки зависимостей;
доступные назначения Simulator и фактическое имя целевой среды;
ожидаемое место для журналов и результатов тестирования.

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

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

Для повторного запуска тестовую задачу удобно определить в Fastfile. В таком случае разработчик и CI вызывают один и тот же lane, а схема и цель тестирования не теряются в длинной команде терминала. Документация fastlane описывает параметры run_tests в справочнике действия; конкретные допустимые значения и поведение следует сверять с используемой версией fastlane и конфигурацией проекта.

Ниже приведён шаблон. Названия схемы, проекта, тестового плана и устройства намеренно заменены заполнителями:

lane :verify_tests do
  scan(
    scheme: "<СХЕМА_ПРОЕКТА>",
    devices: ["<ДОСТУПНОЕ_УСТРОЙСТВО_SIMULATOR>"],
    testplan: "<ТЕСТОВЫЙ_ПЛАН_ЕСЛИ_ИСПОЛЬЗУЕТСЯ>",
    result_bundle: true
  )
end

Не копируйте placeholder в рабочую конфигурацию. Подставьте значение, которое существует в текущем проекте и доступно на конкретном узле. Если проект не использует test plan, не добавляйте его только потому, что поле есть в примере. Если требуется запуск только части тестов, сперва определите критерии выбора средствами проекта и затем проверьте, что lane действительно выполняет ожидаемый набор.

Название Simulator нужно брать из списка, доступного на удалённом Mac, а не из записи на другой машине. Набор доступных симулируемых устройств зависит от установленной среды Xcode; поэтому устаревшее имя или несоответствие платформы может выглядеть как ошибка fastlane, хотя причина находится в настройке целевого назначения. Apple отдельно описывает организацию тестов с помощью планов: это полезно, если проекту нужно разделять наборы тестов или управлять обратной связью, но сам план не обязателен для каждого проекта.

Для первичной диагностики используйте прямой вызов lane:

bundle exec fastlane ios verify_tests

Здесь bundle exec нужен только в том случае, если команда проекта опирается на Bundler; если зависимости управляются иначе, используйте существующий в репозитории способ запуска fastlane. Перед настройкой CI проверьте, что команда работает из каталога проекта и получает те же переменные окружения, которые будут доступны автоматическому заданию.

Третий этап: выполните небольшой прогон и разделите причины сбоя

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

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

Разрешение зависимостей. Уточните, какой шаг установки или подготовки остановился и не изменились ли закреплённые проектом зависимости.
Сборка. Проверьте, дошёл ли процесс до компиляции нужной схемы. Ошибка здесь не является ошибкой утверждения теста.
Запуск Simulator. Убедитесь, что выбранное назначение распознано и тестовый процесс перешёл к запуску.
Выполнение тестов. Проверьте, какие тесты стартовали, какие завершились и какое состояние указано в отчёте Xcode.
Завершение задачи. Сопоставьте статус оболочки fastlane с фактическими тестовыми результатами и сохранёнными файлами.

Если команда завершилась ошибкой, не сводите её сразу к «fastlane не работает». Сбой мог возникнуть при разрешении зависимостей, сборке, запуске Simulator или внутри самого теста. Это разные классы причин с разными доказательствами. Для проверки отчёта используйте документацию Apple о запуске тестов и интерпретации результатов, а не только последние строки терминала.

Убедитесь также, что результат соответствует ожидаемой схеме и тестовой цели. Сообщение об успешном завершении процесса не заменяет проверку списка тестов и их статусов: lane мог вызвать не ту схему или выполнить не тот набор, который команда считает обязательным. Если проект использует несколько тестовых планов, зафиксируйте, какой из них применён в данном запуске.

Четвёртый этап: настройте сохранение результатов при ошибке

Для CI недостаточно видеть краткий вывод в терминале. Если задание завершилось неуспешно, инженер должен получить журнал и пакет результатов, чтобы выяснить, не стартовали ли тесты, завершились ли они с ошибками или прервались на этапе сборки. Apple описывает результаты запуска xcodebuild и работу с пакетом в руководстве по выполнению тестов и их интерпретации.

В команде или lane задайте явное место хранения результата поддерживаемым проектом способом. У Xcode для результата тестирования применяется пакет xcresult; при использовании параметров командной строки проверьте их формат и значение в справочнике xcodebuild. Не предполагайте, что файл появится в текущем каталоге: путь должен соответствовать реальному каталогу выполнения и механизму сбора артефактов в вашей системе CI.

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

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

Результатный пакет облегчает разбор, но не исправляет тест и не гарантирует, что ваша CI-система его сохранит. Правило загрузки файлов и срок их хранения настройте отдельно в используемой системе. В качестве примера того, как fastlane описывает вызов тестов в CI, можно изучить руководство по интеграции fastlane с CircleCI; это справочный пример, а не требование использовать конкретную платформу.

Сравнение вариантов запуска и оценка готовности

Выбор между запуском на рабочей машине, временным удалённым узлом и постоянно обслуживаемым CI зависит от повторяемости нагрузки, контроля среды и того, кто отвечает за сохранение результатов. Оценки ниже показывают соответствие сценарию, а не измеряют производительность оборудования.

Вариант	Когда подходит	Основной риск	Оценка для первичного этапа
Локальный Mac	Проект уже проверяется на рабочем устройстве, а задача не должна быть доступна постоянно	Результат зависит от локальной конфигурации и занятости машины	Высокая для первичной проверки
Удалённый Mac по запросу	Нужно проверить проект на отдельном Mac, не покупая устройство до подтверждения процесса	Перед подключением CI надо испытать доставку проекта и получение результатов	Высокая для пробного прогона
Постоянный Mac-узел CI	Задачи запускаются регулярно, а команда готова поддерживать узел, обновления и сбор артефактов	Обслуживание и восстановление входят в ответственность команды	Высокая после приёмки
Linux-узел без Mac-среды	Подходит для задач проекта, не требующих выполнения инструментов macOS	Не заменяет запуск Xcode-тестов в требуемой среде Mac	Низкая для данного тестового шага

Решение о переходе к постоянному CI принимайте по фактам, а не по первому зелёному запуску. Если проект воспроизводится на удалённом Mac, цель доступна, результат можно получить после неуспеха и повторный запуск не требует ручного восстановления среды, узел можно включать в рабочую схему. Если хотя бы один пункт не подтверждён, оставьте задачу в пробном режиме и устраните конкретный пробел.

FAQ: проверка среды, Simulator и результатов

Как проверить, что выбран правильный Simulator?

Сравните заданное в lane имя с тем, что доступно выбранному Xcode на удалённом Mac. Затем убедитесь, что CI запускает fastlane в том же пользовательском окружении, в котором выполнялась проверка списка назначений. Если Simulator не найден, проверьте выбранный Xcode, платформу и доступность цели до изменения тестового кода: подмена устройства может скрыть расхождение конфигураций.

Как сохранить результат при неуспешном запуске?

Настройте явный каталог для результатов и предусмотрите сбор файлов независимо от статуса тестовой команды. После контролируемого сбоя проверьте не только наличие xcresult, но и возможность скачать и открыть его вместе с журналом. Если система CI удаляет рабочую директорию после неуспеха, артефакты следует копировать до очистки, а не полагаться на сохранение временных файлов.

Показывает ли успешный запуск, что приложение проверено на реальном устройстве?

Нет: тесты в Simulator выполняются в симулируемой среде. Apple описывает различия между запуском приложения на симуляторе и физическом устройстве. Если проверяемое поведение зависит от оборудования или условий реального устройства, запланируйте дополнительный этап и не обозначайте его как пройденный на основании только scan.

Пятый этап: примите решение после повторного прогона

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

Для приёмки используйте условия, а не общее впечатление:

Подключайте задачу к CI, если повторный запуск не требует ручного выбора Xcode или Simulator, а тестовый результат и журнал доступны для проверки.
Оставьте узел в режиме испытания, если тесты проходят, но сбор артефактов, повторяемость или восстановление после сбоя ещё не проверены.
Измените план тестирования, если проекту необходимы проверки на физическом устройстве: Simulator не подтверждает их выполнение.

Если проект требует проверки поведения приложения на конкретном устройстве, добавьте её как отдельную приёмку. Документация Apple о запуске на симулируемых и физических устройствах помогает обозначить границу, но конкретный набор устройств и критерии должны определяться требованиями самого приложения.

Перед постоянной эксплуатацией проверьте также восстановление после перезапуска или сбоя узла. Необходимо выяснить, откуда CI получает исходный код, как повторно подготавливаются зависимости и куда попадают файлы результата. Если после восстановления команда начинает работать только после ручного входа или открытия Xcode, это пока не автономная задача CI.

В итоге fastlane scan полезен как единый вход для тестов проекта, если Mac, Xcode, схема и цель Simulator настроены явно, а результаты сохраняются и после неуспешного задания. Для самого первого подтверждения достаточно одного реального тестового набора и повторного прогона; расширять процесс на весь CI следует после проверки получения артефактов и восстановления узла.

Если сейчас тесты выполняются на перегруженном локальном Mac, вы ограничены доступностью этой машины и её текущей конфигурацией; если используется Linux-сервер, он не предоставляет требуемую macOS-среду для запуска Xcode-тестов. Покупка отдельного Mac решает вопрос владения, но оставляет команде расходы на устройство и его обслуживание. Чтобы предварительно ознакомиться с вариантами удалённого доступа к Mac, можно изучить описание сервиса VNCMac; для временной проверки или запуска тестового узла аренда Mac у VNCMac может быть уместна после пробного прогона. Сначала подтвердите на своём проекте доступность нужного инструментария и получение результатов, затем сопоставьте задачу с вариантами аренды Mac. Если тесты нужны непрерывно и команда готова самостоятельно поддерживать постоянный узел, сравните аренду с покупкой; если же требуется физический доступ к устройству или длительная стабильная нагрузка, выбирайте схему, которая действительно покрывает эти требования.

Дополнительное чтение