ИИ-разработка 1 сентября 2026 г. ~12 мин AppIntentsTesting App Intents

Автоматическое тестирование AppIntentsTesting: руководство по развёртыванию на удалённом Mac 2026

Руководство предназначено для независимых разработчиков и небольших команд, которые проверяют App Intents, Entity Query и интеграцию со Spotlight. Мы показываем, какие сценарии автоматизировать первыми, как изолировать тестовые данные, настроить подпись на удалённом Mac и не принять Beta-инструмент за замену ручной проверке Siri и Shortcuts.

Автоматическое тестирование AppIntentsTesting: руководство по развёртыванию на удалённом Mac 2026

Руководство предназначено для независимых разработчиков и небольших команд, которые проверяют App Intents, Entity Query и интеграцию со Spotlight. Мы показываем, какие сценарии автоматизировать первыми, как изолировать тестовые данные, настроить подпись на удалённом Mac и не принять Beta-инструмент за замену ручной проверке Siri и Shortcuts.

Если ручная проверка Shortcuts проходит, но ошибка в Entity Query обнаруживается только после жалобы пользователя, выбирайте автоматическое тестирование AppIntentsTesting в отдельном UI Testing Target и запускайте его на постоянно доступном удалённом Mac. Такой контур проверяет реальную цепочку Intent, Entity, Query и системной интеграции, но на этапе Beta должен дополнять, а не отменять ручную проверку Siri и Shortcuts.

Кому подходит этот материал

Эта схема предназначена для независимых разработчиков, уже подключивших App Intents и опасающихся незаметных регрессий в Siri, Shortcuts или Spotlight. Она также подходит небольшой команде, которой нужна проверка Intent и Entity Query после каждого изменения.

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

Последнее обновление — 1 сентября 2026 года; сведения о состоянии Beta, Xcode 27 и iOS 27 сверены с официальными записями о выпусках Apple и требованиями к Xcode.

01

Что именно проверяет AppIntentsTesting

AppIntentsTesting не является ещё одним набором обычных unit-тестов с Mock-объектами. Тестовый процесс обращается к коду App Intents приложения и позволяет проверять поведение, от которого зависят пользовательские команды, параметры, сущности и системные поверхности. В официальной документации это выделено в самостоятельный подход к проверке кода App Intents, а примеры Apple показывают связь тестового Target с приложением и его окружением: руководство по тестированию App Intents.

Разница между слоями важна:

  • Обычный unit-тест проверяет изолированную функцию, например преобразование строки в идентификатор. Он не доказывает, что система обнаружит Intent или правильно передаст ему параметр.
  • XCUITest управляет интерфейсом, но успешный клик по экрану не гарантирует корректную регистрацию App Intent, работу Query или появление Entity в Spotlight.
  • AppIntentsTesting проверяет цепочку, в которой тестовый процесс обнаруживает Intent, преобразует входные данные и выполняет его в контексте приложения.
  • Ручная проверка Siri и Shortcuts остаётся необходимой для оценки распознавания речи, формулировок, разрешений, визуального ответа и реального пользовательского опыта.
  • Проверка Spotlight отдельно подтверждает индексацию и поиск Entity; она не сводится к тому, что Intent успешно выполнился.

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

  1. тест не обнаружил Intent — проблема Target, регистрации, Bundle Identifier или сборки;
  2. Intent найден, но параметр не преобразовался — проблема типа, Entity Query или идентификатора;
  3. параметры приняты, но выполнение завершилось ошибкой — проблема бизнес-логики, разрешений или состояния приложения.

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

02

Связка Target, Bundle Identifier и подписи

AppIntentsTesting следует размещать в UI Testing Target, потому что проверяемый код должен быть доступен через реальный процесс приложения и системную интеграцию, а не только через вызов внутренних методов. При настройке необходимо сопоставить:

  • приложение, в котором объявлены App Intents;
  • UI Testing Target, содержащий тестовый код;
  • Bundle Identifier приложения и идентификатор тестового Target;
  • одну и ту же команду подписи для приложения, теста и связанных компонентов;
  • схему сборки, в которой тестируемое приложение действительно устанавливается на выбранный симулятор.

Нельзя подставлять в документацию реальные идентификаторы проекта, Team ID, имена сертификатов, адреса узлов, учётные данные или пути файлов. В примерах используйте значения вроде com.example.product, com.example.product.uitests, <TEAM_ID> и <TEST_DATA_PATH>. Перед публикацией проверьте, что тестовый Target не попал в архив производственной сборки и что отладочные Intent недоступны пользователю.

На удалённом Mac подпись становится отдельным источником отказов. После перезапуска должны восстанавливаться Xcode, сертификаты, provisioning profiles и доступ к команде разработки. Для синхронизации подписывающих идентификаторов используйте рекомендации из официального материала о передаче сертификатов команды, а секреты храните вне исходного кода и журналов.

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

03

Entity Query и передача параметров

Entity Query — участок, который чаще всего ломает пользовательскую цепочку без очевидной ошибки в основном интерфейсе. Внутри приложения список может отображаться правильно, но Shortcuts не найдёт нужную сущность, вернёт неверный элемент или не сможет продолжить следующий Intent.

Проверяйте три независимых поведения:

  • поиск Entity по строковому запросу;
  • разрешение стабильного идентификатора в конкретный объект;
  • возврат всех полей, которые следующий Intent использует как вход.

Тестовые данные должны быть фиксированными. Создайте набор объектов с уникальными, но обезличенными значениями, например Test Item Alpha и Test Item Beta, если эти значения не совпадают с данными реального пользователя. Перед тестом создайте или восстановите набор, после теста удалите его. Не используйте записи из личной базы разработчика: изменение имени, удаление объекта или параллельный запуск сделают результат недетерминированным.

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

  • строки запроса ожидаемому объекту;
  • идентификатора объекта исходной записи;
  • отображаемого имени;
  • переданного значения во втором Intent;
  • итогового состояния после выполнения.

Если Query возвращает несколько совпадений, зафиксируйте правило выбора или ожидаемый набор, а не принимайте первый элемент списка. Иначе перестановка данных будет выглядеть как случайный сбой. Если Query не возвращает ничего, отдельно запишите, был ли объект создан, доступен ли нужному Target и использовался ли тот же идентификатор, который был передан предыдущим Intent.

Именно так AppIntentsTesting отвечает на вопрос о проверке Entity Query и параметров: не через Mock-ответы, а через контролируемый набор Entity, реальное преобразование входа и проверяемый результат следующего Intent.

04

Spotlight и навигация к интерфейсу

Интеграция со Spotlight требует другой диагностической границы. Успешное выполнение Intent не означает, что известная Entity уже проиндексирована. Для проверки используйте тестовый сценарий, который создаёт определённую Entity, запускает индексирование и выполняет поиск по заранее известному значению. Рекомендации по публикации App Entities в системном поиске собраны в документации Apple по доступности Entity в Spotlight, а общие возможности индексации описаны в документации Core Spotlight.

Результат нужно классифицировать, а не сводить к «Spotlight не нашёл»:

  • индекс ещё не создан;
  • индекс содержит устаревшую версию данных;
  • запрос составлен неверно;
  • Entity присутствует, но открывает неправильный экран;
  • приложение не предоставило ожидаемую аннотацию интерфейса.

Для последнего случая применяйте тестовый Intent навигации, который открывает заранее определённую страницу. Затем проверьте View Annotation: Entity должна быть связана с правильным экраном и правильным идентификатором. Путь, название страницы и образец данных должны быть тестовыми и не должны раскрывать личные записи.

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

05

Изолированное состояние и отладочные Intent

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

Для этого удобно добавить несколько Intent, существующих только в отладочной сборке:

  • Intent инициализации создаёт фиксированные тестовые Entity;
  • Intent навигации открывает определённый экран;
  • Intent очистки удаляет тестовые объекты и возвращает окружение в исходное состояние.

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

Минимальная последовательность подготовки выглядит так:

  1. Установите приложение и тестовый Target на чистый или явно сброшенный симулятор.
  2. Запустите инициализацию с фиксированным набором данных.
  3. Проверьте строковый поиск Entity и разрешение идентификатора.
  4. Передайте результат первого Intent во второй и проверьте итоговое состояние.
  5. Выполните индексацию, запрос Spotlight и переход к нужному экрану.
  6. Запустите очистку, затем повторите проверку, что старые записи не находятся.
  7. Сохраните результат теста и сведения об окружении до удаления временных файлов.

Если тесты запускаются параллельно, каждому процессу нужен собственный namespace данных или отдельный симулятор. Общая база с одинаковыми идентификаторами недопустима: один тест может удалить объект, который ещё проверяет другой.

06

Сценарий CI на удалённом Mac

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

Маршрутизацию разделите на независимые задачи:

  • unit-тесты — быстрый контроль чистой логики;
  • UI-автоматизация — проверка интерфейсных переходов;
  • AppIntentsTesting — Intent, Entity Query, параметры и связь с приложением;
  • Spotlight-проверки — индексирование, поиск и View Annotation;
  • релизная сборка — официальная подпись, архив и подготовка публикации.

Такое разделение делает сообщение об отказе конкретным. Если упал unit-тест, искать проблему в удалённом сеансе не нужно. Если не прошёл AppIntentsTesting после успешной сборки, проверяйте установку, подпись, состояние приложения и тестовые данные. Если упал Spotlight, не следует автоматически менять Query: сначала убедитесь, что индекс успел создаться и тест действительно работал с новой Entity.

На удалённом Mac после перезапуска последовательно проверяйте:

  1. установленную версию Xcode и нужный SDK;
  2. наличие требуемого симулятора и его runtime;
  3. доступ к подписывающей команде без передачи секретов в открытом виде;
  4. установку приложения и UI Testing Target;
  5. запуск тестового Intent и создание тестовых данных;
  6. сохранение xcresult, консольного журнала и описания окружения;
  7. выполнение очистки даже после неудачного прогона.

Сохраняйте xcresult, логи сборки, сведения о версии macOS, Xcode, SDK, симулятора, схеме, подписи и результате перезапуска. Это позволяет расследовать отказ без постоянного просмотра удалённого рабочего стола. Время выполнения, процент успешных прогонов и стабильность нельзя объявлять универсальными характеристиками: их следует публиковать только как результат измерения на конкретной конфигурации и дате.

Для удалённого доступа заранее проверьте, какой канал нужен команде: VNC удобен для первичной настройки и ручной проверки, SSH — для команд сборки и журналов, веб-консоль — для аварийного входа, если она предусмотрена выбранной услугой. Пароли, токены, Team ID и пути к ключам в отчётах заменяйте на <REDACTED>.

07

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

Критерий Локальный Mac Облачный CI без постоянной машины Удалённый Mac как выделенный узел
Контроль Xcode и SDK Высокий, но зависит от личного компьютера Ограничен доступным образом среды Высокий при закреплённой среде
Сохранение состояния симулятора Обычно доступно Часто окружение создаётся заново Можно контролировать и проверять после перезапуска
Доступ к UI и ручной проверке Непосредственный Зависит от интерфейса сервиса Доступен через удалённую сессию
Подпись и секреты Настраиваются локально Нужно доверять переменным и хранилищу CI Можно разделить тестовый узел и секретное хранилище
Подходит для длительной регрессии Только если Mac постоянно включён Да, если поддерживаются нужные тесты Да, при автоматическом запуске и сборе артефактов
Основной риск Личный Mac занят или выключен Непредсказуемая версия окружения Ошибка первоначальной настройки и обслуживания

Наш рейтинг для независимого разработчика:

  • AppIntentsTesting на локальном Mac — 4/5: лучший вариант для разработки и ручной диагностики, но не всегда подходит как постоянно работающий узел.
  • Эфемерная среда CI — 3/5: удобна для чистых прогонов, однако состояние симулятора, доступность нужного runtime и подпись требуют дополнительной проверки.
  • Выделенный удалённый Mac — 4,5/5 для регулярной интеграционной регрессии: он сочетает постоянное окружение и удалённый доступ, но требует дисциплины в секретах, обновлениях и восстановлении.

Оценка является решающим инструментом, а не заявлением о производительности. Если проект активно меняет App Intents, важнее повторяемость и артефакты; если интеграция экспериментальная, достаточно локального Target и короткого набора тестов.

08

Состояние Beta и границы применения

На 1 сентября 2026 года Apple официально публикует документацию App Intents Testing и примеры WWDC26, однако Xcode 27 остаётся Beta. В официальной ленте релизов указан Xcode 27 beta 6 от 24 августа 2026 года, а последней опубликованной тестовой сборкой iOS 27 на ту же дату является beta 7 — эти сведения необходимо перепроверять перед развёртыванием по ленте выпусков Apple.

Следовательно, нельзя обещать, что API, системные требования, формат результата или известные ограничения останутся неизменными после RC и финального релиза. Рабочий процесс должен содержать повторную проверку после выхода Xcode 27 RC или стабильной версии:

  • пересобрать приложение и UI Testing Target;
  • повторить Intent и Entity Query;
  • проверить передачу результата между двумя Intent;
  • заново проверить Spotlight и View Annotation;
  • выполнить перезапуск удалённого узла;
  • сравнить xcresult и журналы с предыдущей эталонной сборкой.

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

09

Минимальный критерий перехода к постоянному узлу

Сначала запустите на локальном Mac небольшой набор, состоящий из базового Intent, Entity Query, двух связанных Intent, Spotlight-поиска и проверки восстановления после перезапуска. Если хотя бы один из сценариев зависит от личной базы, ручного входа или неочищаемого состояния, не переносите его в CI: сначала изолируйте данные и замените реальные значения заполнителями.

Переход к постоянному удалённому Mac оправдан, когда проект проверяет App Intents при каждом существенном изменении, нуждается в ночном прогоне или не имеет постоянно включённого Apple silicon Mac. Для разового прототипа, длительной тяжёлой локальной разработки или задач, требующих физического интерфейса устройства, аренда не является универсальной заменой собственной машине.

Существующая схема на Windows или Linux имеет три реальных ограничения: отсутствует нативный macOS-инструментарий, приходится зависеть от непостоянной среды CI, а диагностика подписи и состояния симулятора становится менее прозрачной. Если вместо этого нужен собственный узел с фиксированным Xcode 27, удалённый Mac от VNCMac даёт более предсказуемую основу для тестов через VNC, SSH или веб-консоль; варианты периодов и условия можно сопоставить на странице аренды Mac. Перед заказом проверьте собственным тестовым набором создание Entity, выполнение связанных Intent, Spotlight, повторный запуск и сохранение xcresult, а не только возможность открыть рабочий стол.

Если нужен именно временный тестовый контур для Beta, миграции или проверки перед релизом, аренда удалённого Mac обычно практичнее покупки отдельного устройства: не требуется замораживать бюджет в железе, постоянно держать его включённым и самостоятельно организовывать удалённый доступ. Для постоянной многолетней нагрузки с предсказуемым объёмом сборок собственный Mac может оказаться рациональнее — решение следует принимать после сравнения фактического графика тестов, требований к физическим устройствам и срока эксплуатации.

Начните с условий аренды Mac, скачайте собственный список приёмки из описанных сценариев и выполните два независимых прогона — до и после перезапуска. Так будет понятно, нужен ли проекту постоянный удалённый узел или пока достаточно локального AppIntentsTesting.