Успешно протестировано, что решение i40west работает для ручного запуска симулятора, но кажется глупым, что в наши дни симулятор iOS требует разных версий Xcode И разных типов устройств при выполнении параллельных тестов из командной строки (немного другой вариант использования, но связанный с исходным вопросом вверху ).
См. Статью Apple здесь, которая наиболее актуальна для сборок и тестов командной строки:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Множественные параллельные тесты сработали для нас, если передать правильный --args - в 'iOS simulator.app' перед запуском команды 'xcodebuild test' с правильным значением '-destination', совпадающим с запуском симулятора со значением UUID из вывода 'xcrun simctl list 'и установка переменной среды DEVELOPER_DIR для выбора различных двоичных файлов версии XCode (т.е. базовый путь к Xcode 6.1 и 6.4)
Причина, по которой необходимы параллельные модульные тесты на одной физической машине и на одном и том же устройстве-симуляторе iOS, таком как iPad или iPhone и одна и та же версия Xcode, заключается в первую очередь в поддержке CI (непрерывной интеграции) любого проекта iOS, в результате чего одна и та же система сборки может запускать более 1 сборки из нескольких приложений (у нашей компании около 30 приложений) одновременно при регистрации, ветки функций автоматически сканируются и создаются агентом Bamboo без необходимости ждать завершения других запущенных сборок - Bamboo поддерживает этот тип автоматической сборки на автоматическом обнаруженные функциональные ветви, если они включены.
Что касается того, что происходит при запуске нескольких параллельных тестов, мы запускаем несколько команд «xcodebuild test» дважды подряд в разных окнах Terminal.app, в результате появляется только одно окно симулятора, и тесты не проходят в простейшем тесте.
Когда мы усложняем критерии входа для нашего тестового запуска, разные версии Xcode для каждой sim-карты и тестового запуска, при использовании DEVELOPER_DIR в соответствии с страницами руководства (тест xcodebuild) мы указываем другое устройство, которое открывается в двух отдельных окнах, но в результате любые запущенные тесты в первом окне прерываются вторым окном симулятора iOS.
Похоже, что под капотом есть общий общий ресурс, который мешает, не уверен, что он предназначен, или просто новая функция, которая требует более нескольких дней серьезных размышлений о том, как лучше реализовать параллельные запуски тестов без неблагоприятных воздействий.
Мы не хотим использовать виртуальные машины для обхода ограничений симулятора, поскольку наш опыт и опыт других людей в целом показывают, что производительность сборки iOS на виртуальных машинах с большим количеством небольших файлов ниже, чем на физическом оборудовании. Виртуальные машины обычно значительно замедляют сборку из-за проблем с вводом-выводом в сочетании программного обеспечения VMware и оборудования и / или прошивки Apple. Извините, что виртуальные машины не работают хорошо - сайт фактически гетто предоставил нам инструкции по установке ESXi 5.5 на Mac Mini для нашей фермы сборки.
Мы столкнулись с проблемой производительности сборки, когда ESXi 5.5 на Mac Mini был медленнее, чем голый металл, даже с твердотельным накопителем в 2 или более раз (т. Е. 10-минутная сборка без сборки занимает 20 минут на виртуальной машине). Обратитесь к статье ниже о том, почему.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
Ограничение одного устройства sim за раз для модульных тестов xcodebuild серьезно снижает производительность и экспоненциально увеличивает расходы Apple и экосистемы.
Следует тщательно продумать затраты Apple на отказ от поддержки параллелизма для оправдания покупки большего количества оборудования, взвесив риски потери скорости разработки по сравнению с другими конкурентами, у которых меньше ограничений с точки зрения симуляторов и лицензионного соглашения.
Преимущество параллельных тестов при входе в систему одного и того же пользователя (как работает большинство систем ci) заключается в том качестве приложений из магазина приложений под брендом Apple, которое, в свою очередь, отчасти заставляет людей покупать устройства iOS. Низкое качество программного обеспечения делает работу всего бренда более медлительной, а поддержка параллелизма в симуляторах iOS определенно кажется разумным способом поддержки экосистемы. Некоторым следствием рассматриваемой проблемы являются недавние улучшения, такие как сервер Apple Xcode для CI, функции автоматизированных тестов пользовательского интерфейса Xcode в Xcode 7.
Поощрение ненужных накладных расходов, чтобы заставить людей покупать массовое количество оборудования, настройки, конфигурации, не говоря уже о том, что множество людей требуется для поддержки всех машин, сетей, точек питания и т. Д., Потенциально может нанести ущерб прибыли Apple, поскольку не все такие, как Apple и может позволить себе стойки MacPro или Mac Mini только для поддержки одновременных тестов на симуляторах. Весь смысл симулятора состоит в том, чтобы избежать использования оборудования, а также ускорить тесты.
Кроме того, ограничения EULA для виртуальных машин делают аргументы в пользу виртуальных машин на Mac Pro довольно слабыми. Этот тип оборудования был бы привлекательным, если бы можно было запускать несколько симуляторов, но поскольку одновременные модульные тесты не поддерживаются (за исключением двух указанных выше условий - другой версии XCode и другого устройства-симулятора), мы, вероятно, будем придерживаться Mac Mini для построения инфраструктуры.
Эти ограничения Sim и EULA от Apple не только замедляют конвейер сборки, но также добавляют ненужную сложность и стоимость. Это может быть не так важно для небольших приложений, но по мере роста размера и сложности приложений сборка может занять до часа (я слышал, что сборка iOS для Facebook может занять столько времени). Никто не хочет ждать час, чтобы узнать, прошла ли сборка.
Мы знаем о хакерских решениях, таких как запуск виртуальных машин ESXI на Mac Minis, которые не очень хорошо работают с OS X и xcodebuild в крупных проектах со сборками, которые занимают более 10 минут на современных Mac Book Pro или Mac Mini, или с разными учетными записями. на голом железе в среду, чтобы иметь возможность запускать параллельные тесты на одной и той же версии Xcode и на том же устройстве-симуляторе.
ESXi официально не поддерживается, хотя работает довольно хорошо. Одной из причин, по которой VMware может не поддерживать оборудование Mac Mini, является отсутствие памяти ECC, хотя Mac Pro поддерживается, поскольку у него есть память ECC, у него, вероятно, есть те же проблемы, что и у Mac Mini, с точки зрения замедления сборки iOS по сравнению с голым металлом. тесты на той же конфигурации оборудования и программного обеспечения (единственное отличие - виртуальная машина по сравнению с голым железом под управлением OS X). MacPro в настоящее время нами не тестировался. По нашему опыту, VMware Fusion также довольно медленный с точки зрения производительности.
Что еще более важно, разработчикам придется ждать дольше, когда вышеупомянутые проблемы будут объединены вместе, если только пул машин не будет достаточно большим, чтобы поддерживать набор изменений (одна сборка CI на каждые 2 разработчика, очень высокое соотношение машин к разработчику). Машины сборки CI должны иметь возможность запускать больше параллельных сборок и больше одновременных тестов, чем 1.
Еще одно наблюдение, касающееся симуляторов iOS, заключается в том, что они, похоже, находятся в стадии разработки и полностью незавершены даже после 7 основных версий. Подкоманда 'xcrun simctl' имеет параметр --set, который может допускать некоторую гибкость, но не уверен в том, какое возможное значение является допустимым, и то же самое с --noxpc. Никто не должен угадывать подходящие значения, и, кроме того, должна быть справочная страница, которая описывает этот параметр и, возможно, пример. Какие варианты использования этих двух интересных вариантов?
Вы можете сказать, что ни одно приложение не должно разрабатываться так, чтобы иметь большой размер, требующий одновременного выполнения тестов, и использовать лучшую архитектуру, основанную на XPC, поскольку проблема заключается в монолитных приложениях. Это вполне может быть правильным, это не такое прагматичное решение, как мы могли бы надеяться, и проблема остается, если у вас есть 20+ приложений для создания в той же инфраструктуре.
Чтобы сделать конфигурацию машины и процессы как можно более общими и масштабируемыми для повышения пропускной способности, потребуется некоторая работа над симулятором (разработчики приложения + ядра). Это также требует высокого уровня сотрудничества между всеми разработчиками симуляторов Apple и владельцами симуляторов, которые должны правильно упорядочить отставание продукта, чтобы эта проблема привлекла внимание :-)
