Xcode 9+

в Xcode 9 теперь поддерживает запуск нескольких тренажеров. Об этом было объявлено в WWDC 2017.

просто пойти и изменить симулятор в Xcode, Cmd + R и вы увидите новый симулятор выскакивает.

успешно протестировано, что решение i40west работает для ручного запуска симулятора, но кажется глупым, что в этот день и возраст симулятор iOS требует разных версий Xcode и разных типов устройств при запуске параллельных тестов из командной строки (немного другой случай использования, но связанный с оригинальным вопросом вверху).

см. статью Apple здесь, которая наиболее актуальна для сборки командной строки и тесты: https://developer.apple.com/library/ios/technotes/tn2339/_index.html

несколько параллельных тестов отлично сработали для нас, если передать правильный --args -- to ' iOS simulator.приложение "перед запуском команды" 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" дважды подряд в разных терминалах.окна приложений, в результате появляется только одно окно симулятора, и тесты терпят неудачу в самом простом тесте.

когда мы усложняем критерии входа для нашего тестового запуска, разные версии Xcode для каждой sim-карты и тестового запуска, при использовании DEVELOPER_DIR согласно man-страницам (xcodebuild test) мы указываем другое устройство, которое открывается в двух отдельных окнах, но в результате любые запущенные тесты в первом окне прерываются вторым окном симулятора iOS.

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

мы не хотим использовать виртуальные машины для работы с ограничениями sim, поскольку наш опыт и другие в целом заключается в том, что производительность сборки iOS на виртуальных машинах с большим количеством небольших файлов медленнее, чем физическое оборудование. Виртуальные машины обычно замедляют сборку на много из-за проблем ввода-вывода в сочетании программного обеспечения VMware и аппаратного обеспечения Apple и/или прошивки. Извините virtuallyghetto, но для нас виртуальные машины не работают хорошо-сайт virtuallyghetto предоставил нам инструкции о том, как установите ESXi 5.5 на Mac Mini для нашей фермы сборки.

мы столкнулись с проблемой производительности сборки с ESXi 5.5 на Mac Mini, которая медленнее, чем голый металл, даже с SSD в 2 раза или более (т. е. 10-минутная сборка baremetal занимает 20 на виртуальной машине). См. статью squareup ниже о том, почему.

https://corner.squareup.com/2015/07/ios-build-infrastructure.html

ограничение 1 sim-устройства одновременно для модульных тестов xcodebuild серьезно снижает производительность и экспоненциально увеличивает значительные затраты на Apple и экосистему.

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

преимущество параллельных тестов в том же логине пользователя (как работает большинство систем ci) заключается в том, что качество фирменных приложений Apple app store, которые в свою очередь, это отчасти то, что заставляет людей покупать устройства iOS в первую очередь. Низкое качество программного обеспечения делает весь бренд немного более вялым, а поддержка параллелизма в симуляторах iOS определенно кажется умным способом поддержки экосистемы. Немного следствием этой проблемы являются недавние улучшения, такие как сервер Xcode от Apple для CI, функциональность автоматизированных тестов пользовательского интерфейса Xcode в Xcode 7.

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

плюс ограничения EULA на виртуальных машинах делает случай для виртуальных машин на Mac Pro довольно слабый. Этот тип оборудования был бы привлекателен, если бы несколько симов могли работать, но поскольку параллельные модульные тесты не поддерживаются (за исключением двух условий - другой версии XCode и другого устройства симулятора), мы, вероятно, будем придерживаться Mac Mini для создания инфраструктуры.

эти ограничения sim и EULA от Apple не только замедляют конвейер сборки, но и добавляют ненужную сложность и стоимость. Это может быть не так важно для небольших приложений, но поскольку приложения растут в размерах и сложность, сборка может занять до часа (я слышал, что Facebook iOS строит может занять столько времени). Никто не хочет ждать час, чтобы узнать, прошла ли сборка.

мы знаем о хакерских решениях, таких как запуск ESXi VMs на Mac Minis, которые не очень хорошо работают с OS X и xcodebuild на больших проектах со сборками, которые занимают более 10 минут на современном Mac Book Pro или Mac Mini, или различные учетные записи для входа на голой металлической машине в окружающую среду, чтобы иметь возможность запускать параллельные тесты на той же версии Xcode и том же устройстве симулятора.

ESXi официально не поддерживается, хотя он работает довольно хорошо. Одна из причин, по которой VMware может не поддерживать аппаратное обеспечение Mac Mini, - это отсутствие памяти ECC, хотя Mac Pro поддерживается, поскольку у него есть память ECC, вероятно, есть те же проблемы, что и у Mac Mini с точки зрения iOS-сборки замедляются по сравнению с тестами на голом металле на той же аппаратной и программной конфигурации (только изменение VM против голого металла под управлением OS X). MacPro не было испытано нами в это время. По нашему опыту VMware Fusion также довольно медленный с точки зрения производительности.

Что еще более важно, разработчикам придется ждать дольше, когда вышеупомянутые проблемы будут объединены вместе, если пул машин не будет достаточно большим, чтобы поддерживать pipleline изменений (одна сборка CI для каждых 2 разработчиков, очень высокое отношение машин к разработчику). Машины сборки CI должны иметь возможность запускать более параллельные сборки и более параллельные тесты, чем 1.

одно из других наблюдений о симуляторах iOS заключается в том, что они, похоже, работают и полностью не завершены даже после 7 основных версий. Подкоманда 'xcrun simctl' имеет параметр --set, который может позволить некоторую гибкость, но не уверен, какое возможное значение допустимо, и то же самое с --noxpc. Никто не должен угадывать соответствующие значения и, кроме того, должна быть страница man, которая охватывает эту опцию и, возможно, пример. Что некоторые используют случаи для этих 2 интересных вариантов?

вы можете сказать, что ни одно приложение не должно быть разработано, чтобы иметь большой объем, который гарантирует одновременный тест для запуска, и использование лучшей архитектуры на основе XPC, поскольку монолитные приложения являются проблемой. Это может быть очень правильно, это не такое прагматичное решение, на которое мы могли бы надеяться, и проблема остается, если у вас есть 20+ приложений для создания одной и той же инфраструктуры.

создание конфигурации машины и процессов как универсальных и масштабируемых по возможности для более высокой пропускной способности потребуется некоторая работа над симулятором (app + core devs). Это также требует высокого уровня сотрудничества между всеми разработчиками симулятора Apple и владельцем (владельцами) продукта симулятора необходимо правильно заказать отставание продукта для этой проблемы, чтобы привлечь внимание: -)

FBSimulatorControl от Facebook предоставляет программный способ сделать это. Он доступен по адресу https://github.com/facebook/FBSimulatorControl.

метод testLaunchesMultipleSimulatorsConcurrently на FBSimulatorControlSimulatorLaunchtests.м есть пример кода, иллюстрирующий, как запустить несколько симуляторов.

вы можете запускать несколько экземпляров симулятора для разных профилей оборудования и отлаживать их. Во-первых, вам нужно запустить приложение из XCode для каждого типа оборудования (iPhone 6, iPad и т. д.) чтобы установить его в экземпляры симулятора. Затем запустите экземпляры симулятора и ваше приложение, как описано выше. Чтобы отладить его, вы можете прикрепить отладчик к запущенным процессам из меню "XCode->Debug->Attach to Process". Вы можете проверить эту запись в блоге для образец :http://oguzdemir.dualware.com/?p=43

вот небольшой скрипт в .sh, чтобы перечислить UDID симуляторов на вашем компьютере и запустить его. Скопируйте приведенный ниже код в файл с расширением ".sh" и запустите его в терминале.

Как:

Шаг 1. Перечислите устройства с опцией 1 и скопируйте нужный UDID

Шаг 2. Запустите опцию 2 и вставьте UDID, затем нажмите клавишу enter

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

#!/bin/sh
PS3='Type the number of your choice (1, 2 or 3) and press Enter: '
options=("List Devices" "Run Simulator" "Quit")
select opt in "${options[@]}"
do
    case $opt in
        "List Devices")
            xcrun simctl list devices
            echo "3[1m\n\nCopy the UDID in parentheses of the device which you want run and launch option 2 (Run Simulator)3[0m"
            ;;
        "Run Simulator")
            read -p 'Type device UDID which you want launch: ' currentDeviceUDID
            open -n /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/ --args -CurrentDeviceUDID $currentDeviceUDID
            ;;
        "Quit")
            break
            ;;
        *) echo invalid option;;
    esac
done

спасибо ты,